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(54) Apparatus and method for object-oriented memory system 



(57) A method and apparatus for providing memory 
functionality to object-oriented client software compo- 
nents of a computer system having a CPU using a first 
set of memory classes, each class of the first set being 
platform-independent; a second set of memory classes, 
each class of the second set being a subclass of a class 

24 



of the first set and being platform-dependent; and per- 
forming client component memory functions by access- 
ing only objects of classes of the first set. Descriptions 
of the classes and methods are provided, enabling plat- 
form-independent device drivers to be implemented. 
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Description 

BACKGROUND OF THE INVENTION 
Field of the invention 

[0001] The invention relates generally to computer 
memory and, more particularly, to memory methods 
and systems which are platform-independent. 

Des cri ption of the Relate^ Art 

[0002] In order for computer systems to communicate 
with the user, the systems usually include a number of 
peripheral devices such as display screen, printers, and 
keyboards. Each of these peripheral devices requires a 
special software component, called a device driver, to 
provide for orderly exchange of data between the 
peripheral device and the rest of the computer system. 
[0003] A company developing, for example, a new 
color printer would like to" insure that the printer will be 
usable with computers having different hardware config- 
urations ("platforms"), including systems based upon 
the most popular types of central processing units, such 
as the SPARC manufactured by Sun Microsystems, the 
PowerPC manufactured by the Motorola Corporation, 
and the Pentium manufactured by Intel Corporation. 
Currently, this requires that the printer manufacturer 
write a separate device driver for each platform, thereby 
driving up the development cost of the printer. Moreo- 
ver, the need for custom device drivers for each platform 
also means that when a new platform is introduced, 
device drivers may not be immediately available for the 
most popular types of peripheral devices. 
[0004] The need for custom device drivers for each 
platform is closely related to the varying memory char- 
acteristics of each platform. It would be desirable to pro- 
vide memory systems and methods which would permit 
a single device driver to be written for a peripheral 
device, thereby allowing operation of the peripheral 
device on all platforms, including new platforms to be 
introduced in the future. 

SUMMARY OF THE INVENTION 

[0005] Features and advantages of the invention will 
be set forth in the description which follows, and in part 
will be apparent from the description, or may be learned 
by practice of the invention. The objectives and other 
advantages of the invention will be realized and attained 
by the apparatus, methods, and articles of manufacture 
particularly pointed out in the written description and 
claims hereof, as well as the appended drawings. 
[0006] To achieve these and other advantages, and in 
accordance with the purpose of the invention as embod- 
ied and broadly described, the invention provides a 
method for providing memory functionality to object-ori- 
ented client software components of a computer system 
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having a CPU. The method comprising the steps of pro- 
viding a first set of memory classes, each class of the 
first set being platform-independent; providing a second 
set of memory classes, each class of the second set 
5 being a subclass of a class of the first set and being 
platform-dependent; and performing client component 
memory functions by accessing only objects of classes 
of the first set. 

[0007] In another aspect, the invention includes appa- 
70 ratus for performing memory functions in an object-ori- 
ented computer system, comprising a first set of 
memory classes, each class of the first set being plat- 
form-independent; a second set of memory classes, 
each class of the second set being a subclass of a class 
15 of the first set and being platform-dependent; a device 
driver accessing only objects of classes of the first set; 
and a bus manager accessing dasses of the second 
set. 

[0003] In yet another aspect, the inventon includes a 

20 computer-readable medium containing instructions for 
providing memory functionality to object -oriented client 
software components of a compute* system having a 
CPU. The instructions compfrse a f*st set of memory 
classes, each class of the first set being platform-inde- 

25 pendent; and a second set of memory ciasses, each 
class of the second set being a subdass of a class of 
the first set and being ptatlam-dependent 
[0009] It is to be understood that both the foregoing 
general description and the following detailed descrip- 

30 tion are exemplary and explanatory and are intended to 
provide further explanation of the invention as claimed. 
[0010] The accompanying drawings are induded to 
provide a further understanding of the rrventon and are 
incorporated in and constitute a part of thts specifica- 

35 tion, illustrate one/several embodiment(s) of the inven- 
tion and, together with the description, serve to explain 
the principles of the invention 

BRIEF DESCRIPTION OF THE DRAWINGS 

40 

[001 1 ] The accompanying drawings, whicfi are incor- 
porated in and constitute a part d this specification, 
illustrate embodiments of the inv^ntjon and. together 
with the description, serve to explain the objects, advan- 
45 tages, and principles of the inventon 
[0012] In the drawings: 

Fig. 1 is a hardware block digram of a computer 
system embodying the present invention, 
50 Fig. 2 is a diagram of object-oriented software of 
the computer system of Fig 1 . 
Fig. 3 is a diagram showing the class hierarchy of 
the memory system portion of the software shown 
in Fig. 2; 
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DETAILED DESCRIPTION OF THE PREFERRED ^ 
EMBODIMENTS 

[0013] Methods and apparatus consistent with the 
present invention are contained in an object-oriented 
operating system. The disclosed embodiment is imple- 
mented in the Java programming environment provided 
by Sun Microsystems, Inc. of Mountain View, CA. How- 
ever, the invention is not so limited and may be incorpo- 
rated into other computer systems, other operating 
systems, and other programming environments, as is 
understood by those skilled in the art. Java, Java- 
related trademarks, Sun, Sun Microsystems, and the 
Sun logo are either trademarks or registered trade- 
marks of Sun Microsystems, Inc. of Mountain View, CA. 
[0014] Reference will now be made in detail to an 
implementation consistent with the present invention , 
as illustrated in the drawings. Wherever possible, the 
same reference numbers will be used throughout the 
drawings and the following description to refer to the 
same or like parts. . 

[0015] Fig. 1 shows a computer system 10 which 
includes the present invention. Computer system 10 
includes a central processing unit (CPU) 12 which may 
be, for example, a Sun SPARC, a Motorola Power PC or 
an Intel Pentium. Computer system 10 may represent a 
wide variety of computing devices. For example, system 
10 may represent a standard personal computer, as 
widely used in homes and offices. Alternatively, system 
10 may comprise a much more specialized "smart" sys- 
tem, such as a set-top box for use in receiving high def- 
inition television, or a multi-function cellular telephone. 
[001 6] CPU 1 2 is connected to memory 1 4 which may 
include various types of memory such as random 
access memory (RAM) and read only memory (ROM). 
CPU 12 is also connected to an expansion bus 16 which 
may be, for example, a PCI bus. Various types of input 
and output devices 19, 20, and 22 are connected to bus 
16. For example, input device 18 may be a modem or 
network interface card connecting system 10 to a tele- 
phone line or local area network. Input device 20 may 
be, for example, a keyboard and output device 22 may 
be, for example, a printer. System 10 may optionally 
include a mass storage device 24, such as a hard disk 
drive connected by an I/O bus 26 which may be, for 
example, a SCSI bus. System 10 also includes a direct 
memory access (DMA) controller 23, under control of 
CPU 12, which can provide direct transfer of data 
between memory 14 and PCI bus 16. 
[0017] Referring now to Fig. 2, there is shown a dia- 
gram of software stored in memory 14 of Fig. 1. Fig. 2 
shows software logically arranged in a series of layers. 
An upper layer 30 is "platform-independent." The term 
"platform" generally refers to a CPU. physical memory, 
and permanently attached devices and buses. Thus, the 
software contained in platform-independent layer 32 is 
written in a manner that it may be used with any plat- 
form, based on any CPU, either existing or to be devel- 



oped in the future, without modification. A second layer 
34 is platform-dependent. Thus, software of layer 34 
must be customized for the particular platform of com- 
puter system 10. 

5 [0018] Platform-independent layer 32 includes an 
application program layer 36 which performs specific 
■ operations for the user, such as desktop publishing, 
managing a telephone call, or database management. 
Application layer 36 interfaces with a runtime system 38 

io which includes a component known as a "Java™ Virtual 
Machine" (JVM). The JVM is a software component 
which receives instructions in the form of machine-inde- 
pendent bytecodes produced by applications programs 
and interprets the instructions by dynamically convert- 

i5 ing and executing them. The JVM interfaces with a spe- 
cific platform to execute desired functions. The 
disclosed embodiment employs a Java Virtual Machine, 
but other types of virtual machines are usable, as 
known to those skilled in the art. The operation of the 

20 JVM is well known to those skilled in the art and is dis- 
cussed in. for example, the book Java! by Tim Ritchey, 
published by New Riders Publishing of Indianapolis, 
Indiana, and in The Java Virtual Machine Specification , 
by Lindham and Yellin. Addison-Wellesley (1997). 

25 [0019] Runtime system 38 also includes a device 
interface portion 42 which supports operation of devices 
such as buses 16 and 26 and devices 18, 20, 22 (Fig. 
1). In particular, device interface 42 includes device 
managers 46 and miscellaneous managers 48. Device 

30 interface 42 also includes device drivers 50 which are 
object-oriented programs written for each of the devices 
18. 20. and 22. Note that device drivers 50 are included 
in platform-independent layer 32, and thus, once writ- 
ten, may be used to support devices 18, 20, and 22 on 

35 any platform both existing and to be developed in the 
future. Similarly, device interface 42 includes platform- 
independent bus managers 53 which are object-ori- 
ented programs written for buses, such as PCI bus 16 
and SCSI bus 26 of Fig. 1 . Device interface 42 also 

40 includes memory classes 52 which form part of the 
present invention and will De discussed below in greater 
detail. 

[0020] Device interface 42 also includes additional 
components such as a system database 56 and a sys- 
45 tern loader 54 which support operation of computer sys- 
tem 10. Similarly, runtime layer 38 includes additional 
functions 58 supporting operations such as input/out- 
put, network operations, graphics, printing, multimedia, 
etc. 

so [0021] Platform-dependent layer 34 includes a plat- 
form interface 60, an OS native methods layer 61. a 
microkernel 62, and a boot interface 64. Platform inter- 
face 60 includes virtual machine system function library 
handlers 66 which may be written in the Java program- 

55 ming language to provide support for system function 
calls received from virtual machine 40. Platform inter- 
face 60 further includes interrupt classes 68 also written 
in the Java programming language which support inter- 
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rupt operations of computer system 1 0 and bus manag- 
ers 44. Finally, platform interface 60 includes direct 
memory access (DMA) classes 70 and memory classes 
72, each written in the Java programming language. 
DMA classes 70 and memory classes 72 are a feature 5 
of the present invention and will be discussed below in 
greater detail. 

[0022] OS native methods layer 61 includes operating 
system methods of classes 68, 70, 72, and 44 which are 
written in a language specific to CPU 12 ("native" Ian- 10 
guage) and which interface with lower-level operations 
of microkernel 62. These methods include interrupt 
native methods 78, DMA native methods 80, and mem- 
ory native methods 82. Methods 80 and 82 will be dis- 
cussed below in greater detail. is 
[0023] Microkernel 62 consists of native-language 
software components which support essential low-level 
hardware functions of CPU 12, such as resource alloca- 
tion, interrupt process, security, etc. In particular, micro- 
kernel 62 includes a plurality of kernel functions 74 20 
including thread management, exceptions, timing, phys- 
ical memory management, hardware interrupt process- 
ing, platform control, process management, library 
management, I/O support, and monitor functions. 
Microkernel 62 further includes debug functions 76. 25 
Functions 74 and 76 may be performed by the Chorus 
microkernel commercially available from Sun Microsys- 
tems. However, other microkernels may be used, as is 
known to those skilled in the art. 

[0024] The final component of platform-dependent 30 
layer 34 is boot interface 64. Boot interface 64 provides 
for loading and initialization of software into memory 14 
(Fig. 1) when computer system 10 is initially powered 
up. Boot interface 64 may load software stored on, for 
example, a floppy disk, mass storage 24 (Fig. 1), or soft- 35 
ware received in the form of a computer data carrier 
wave over a network, via input device 18. Boot interface 
64 forms no part of the present invention and will not be 
discussed in further detail. 

[0025] Referring now to Fig. 3, there is shown a dia- 40 
gram illustrating the hierarchy of memory and DMA 
classes 52, 70, and 72. Memory and DNA Classes 52, 
70, and 72 have the following design goals: 

One platform-independent class for client software 45 
components, such as drivers, to access (read or 
write) memory: Although there could be a variety of 
different types of platforms supported, a driver will 
always use the same platform-independent meth- 
ods of these classes, and only these methods, to so 
read and write memory. Developing device drivers 
written in the Java programming language, which 
are completely independent of the particular plat- 
form, is one of the main goals of the present inven- 
tion. 55 
Methods for Bus Managers to Construct memory 
objects: the present invention encapsulates device 
platform specifics in a handful of bus managers 
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which construct memory objects for the vast array 
of device drivers to use to access memory. The 
Memory classes allow a bus manager to construct 
a generic memory object, which ultimately provides 
access to one of three (as specified by the bus 
manager) fundamental types of memory: 

Regular memory which is accessed via normal 
load and store operations from the CPU. This 
memory could be directly addressed by the 
CPU (i.e.. physical memory), or could be indi- 
rectly accessed through an MMU (i.e. virtual 
memory). 

I/O memory which is accessed via normal load 
and store operations from the CPU, but which 
may also require other operations to be done to 
keep the I/O memory coherent with main mem- 
ory. Again, this memory could be directly 
addressed by the CPU (i.e. physical memory), 
or could be indirectly accessed through an 
MMU (i.e. virtual memory). 
I/O port memory which is accessed via special 
I/O instructions (e.g. in and out instructions on 
Intel x 86-based platforms). 

Methods for the Bus Managers to set up DMA on 
behalf of client drivers. 

Platform independence of the Java programming 
language portions of the Memory and DMA classes 
themselves. 

Support for virtual memory and multiple address 
spaces. Furthermore, the virtual memory sup- 
ported has to be sufficiently general to include plat- 
forms that have no MMU. In such cases, virtual 
address will be the same as physical address, and 
only one virtual address space will be provided by 
the platform. Device drivers will always think they 
are accessing virtual memory, even on systems 
with no MMU and only one virtual address space, 
even though they are accessing physical memory 
directly. 

A sufficiently rich memory model. 
A generic interface to a microkernel, via native 
methods, as shown in Fig. 2. The new Memory and 
DMA classes are designed to interface with a 
generic microkernel. 

[0026] It is important to note in particular that the 
Memory and DMA classes do not provide yet another 
OS memory management subsystem implementation. 
Rather, the functionality for managing virtual memory, 
physical memory, I/O memory, and DMA is provided by 
the microkernel. The Memory and DMA classes do call 
upon such microkernel functionality via native methods, 
but these classes leverage that functionality, rather than 
reinventing it. 

[0027] More detailed discussion of the classes shown 
in Fig. 3 is set forth below. 
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Memory Abstract Class ' 

[0028] At the highest level, each of the Memory and 
DMA classes is eventually a sub-class of the Memory 
abstract class, which only has the notion of such gen- s 
eral attributes as a base address, length, and con- 
straints (of both access and allocation). Below that, 
memory is either ultimately accessible (perhaps not 
always directly, as in the case of physical memory) by a 
CPU, hence MainMemory, or it is accessed externally 
to the CPUs via DMA, hence DMAMemory. 

MemoryDescrlptor Class 

[0029] Having a non-abstract and hence instantiate 
sub-class of Memory proves useful for representing fun- 
damental characteristics of memory, such as base 
address and length, before an actual memory object 
has been constructed. Other than being instantiate, 
the MemoryDescriptor class does not provide any addi- 
tional functionality b9yond that provided by Memory. 
This is useful for bus managers to represent abstract 
memory before it is actually allocated. 

MainMemory Abstract Class 

[0030] The MainMemory abstract class only specifies 
abstract methods for managing caching, which is the 
only functionality common to its sub-classes. Eventually 
in the hierarchy (in PhysicalMemory, VirtualMemory, 
and PortlOMemory), these abstract cache management 
methods are implemented. It is important to note that 
cache management is highly platform-dependent, and 
thus each of these implementations ultimately relies on 
invoking the microkernel to flush caches, set the cache 
mode, etc. Therefore, the device driver has full access 
to complete cache functions using platform-independ- 
ent methods of MainMemory 

MainMemory is either the abstract class, 
AccessibleMemory, which represents all memory that 
can be directly accessed by a CPU, or it is the 
PhysicalMemory class, which represents physical 
memory, which in general may not always be directly 
accessed by a CPU. 

DMAMemory Class 

[0031] The DMAMemory class provides methods for 
setting up DMA mappings to physical memory (ulti- 
mately done by the microkernel running below these 
classes), and for doing the corresponding unmapping. 
The decision was made to have the microkernel ulti- 
mately set up DMA mappings, since the full range of 
DMA hardware to be supported would not be something 
that it would be good to try to abstract at the 
DMAMemory class level, since doing so would be rein- 
venting functionality that the microkernel must already 
support, and since it would probably not be possible to 
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develop a sufficiently general scheme that deals with all 
the conceivable flavors of DMA hardware. 
[0032] Note in particular that the DMAMemory object 
is not concerned with whether the DMA addresses that 
the microkernel sets up for it are virtual DMA addresses 
that map through some IOMMU to physical DMA 
addresses, or whether the DMA addresses are physical 
DMA addresses. The addresses are simply DMA 
addresses, and such mappings are transparent to 
io DMAMemory and entirely maintained by the microker- 
nel. 

[0033] Device drivers can thus obtain a base address, 
using methods of DMAMemory described in detail 
below, which can be passed to the DMA controller, 
15 thereby allowing device drivers to provide full DMA func- 
tionality in a completely platform-independent manner. 

AccessibleMemory Abstract Class 

20 [0034] AccessibleMemory is what is given to drivers 
by bus managers, so that they can always access mem- 
ory in a platform-independent manner, thus allowing 
them to be portable across all platforms. 
AccessibleMemory thus defines platform-independent 
25 abstract methods, such as setByteQ. Drivers should 
only use the methods abstracted in AccessibleMemory 
or methods abstracted or implemented by the super- 
classes of AccessibleMemory, which are MainMemory, 
and Memory Classes below AccessibleMemory, and 
30 also PhysicalMemory and DMAMemory should only be 
accessed by bus managers, which understand platform 
specifics. That way, platform specifics will not creep into 
driver code. AccessibleMemory is either accessed by a 
CPU issuing normal load and store instructions, hence 
35 VirtualMemory or it is accessed by a CPU issuing spe- 
cial I/O port instructions, hence PortlOMemory. 

PhysicalMemory Class 

40 [0035] In this memory model, PhysicalMemory is not 
accessible, because even on systems that do not have 
MMUs. the abstraction is maintained that the CPUs are 
really accessing virtual memory (not physical memory) 
that happens to be mapped one-to-one to physical 
45 memory. This abstraction thus provides a means of 
handling systems with and without MMUs in the same 
general way. Since the PhysicalMemory class is a sub- 
class of the abstract class, MainMemory 
PhysicalMemory provides implementations of the 
so cache management methods abstracted in MainMem- 
ory. 

The PhysicalMemory class allows a bus manager to 
specify a range of physical addresses, perhaps for reg- 
isters of a device driver. By itself, though, since 
55 PhysicalMemory cannot be accessed, it is not useful. 
But, there are methods of VirtualMemory and of 
DMAMemory for mapping this physical memory into vir- 
tual memcry or DMA, respectively. 
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VirtualMemory Abstract Class 

[0036] The VirtualMemory abstract class contains 
methods for setting up mappings to PhysicalMemory 
objects (mappings ultimately set up by the microkernel). 
As mentioned above, even on systems with no MMUs, 
VirtualMemory objects are mapped one-to-one to 
PhysicalMemory objects. The VirtualMemory class also 
has a method for allocating a specific amount of virtual 
memory (also ultimately done by the microkernel), with- 
out specifying any particular physical memory. There is 
even a method which then allows one to obtain an array 
of the underlying PhysicalMemory objects for a 
VirtualMemory object, which is especially useful when 
PhysicalMemory objects were not passed to construct 
the VirtualMemory object in the first place. It is possible 
for a bus manager to set up DMA to virtual memory, 
since, given a VirtualMemory object, the array of under- 
lying PhysicalMemory objects can be obtained, and 
then passed to a method of DMAMemory to set up 
DMA. VirtualMemory class also supports lock() and 
unlockQ methods that can be used before obtaining 
underlying physical memory parameters before setting 
up a DMA operation. As set forth in detail below, there is 
even a lockContiguous() method, which makes sure the 
underlying physical pages mapped are contiguous, 
which is necessary on platforms that do not have a 
means, such as an IOMMU, of doing scatter-gather. It 
is, of course, up to the specific bus manager, which 
understands platform specifics, to decide what methods 
are needed for the specific platform. 
[0037] The VirtualMemory abstract class also imple- 
ments cache management methods (ultimately per- 
formed by the microkernel), which are abstracted by 
MainMemory These methods, too, depending upon the 
coherency characteristics of the platform (also platform 
specifics known by the bus manager), are useful when 
setting up DMA. 

PortlOMernory Abstract Class 

[0038] The other type of AccessibleMemory besides 
VirtualMemory is PortlOMernory, which is intended for 
CPUs issuing special port I/O operations, such as the 
Intel x86 series. The PortlOMernory abstract class itself 
only implements the cache management operations 
abstracted by MainMemory. In this case, though, there 
is no caching, and these methods do not do much. 

SwappedPortlOMemory and 
UnSwappedPortlOMemory Classes 

[0039] The bulk of the support for PortlOMernory is in 
its two sub-classes, SwappedPortlOMemory and 
UnSwappedPortlOMemory, which each implement 
all the memory access methods abstracted by Accessi- 
bleMemory. As the names would imply, one does byte- 
swapping of the data written (to support different endi- 
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anness between the CPU and memory), and the other 
does not. It is up to the bus manager (which knows such 
endianness) to decide which of these two to instantiate, 
[0040] The reason for having two classes, one for 

5 swapped and one for unswapped, is so it is not neces- 
sary to have a conditional that checks for whether or not 
memory is byte-swapped in each of the native methods. 
Also, the driver should not be required to know whether 
or not memory is swapped, since that would run counter 

10 to the need for full driver platform independence. 

VirtuallOMemory and VirtualRegularMemory 
Abstract Classes 

15 [0041] VirtualMemory is either mapped to I/O 
space, hence VirtuallOMemory, or it is not, hence 
VirtualRegularMemory. The reason for the two differ- 
ent abstract classes is that on some platforms 
accesses to I/O space may also require operations to 

20 flush out the pipeline. Both VirtuallOMemory and 
VirtualRegularMemory currently provide no functional- 
ity, but instead leave it to sub-classes to provide all func- 
tionality. Each of these two classes is only included in 
case there is ever anything common to its sub-classes 

25 that should be abstracted at a level higher. 

SwappedVirtuallOMemory and 
UnSwappedVirtuallOMemory Classes 

30 [0042] Similarly to PortlOMernory VirtuallOMemory 
has two sub-classes, SwappedVirtuallOMemory and 
UnSwappedVirtuallOMemory which each implement 
all the memory access methods abstracted by Accessi- 
bleMemory 

35 

SwappedVirtualRegularMemory and 
UnSwappedVirtualRegularMemory Classes 

[0043] Also similarly to PortlOMernory, 
to VirtualRegularMemory has two sub-classes, 
SwappedVirtualRegularMemory and 
UnSwappedVirtualRegularMemory, which each imple- 
ment all the memory access methods abstracted by 
AccessibleMemory 

45 

Addresses 

[0044] DMA memory, physical memory, and virtual 
memory are all addressed by addresses from the same 
so Address abstract class. Since there are significant 
example of systems that have addresses with non- 
power-of-two number of bits, the Address class sup- 
ports addresses with any number of bits between 1 and 
64. 

55 

Unsigned Values Representing Addresses 

[0045] Internally to the class, an Address object is 
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represented as an unsigned value, along with an indica- 
tion of the number of bits. Since the Java programming 
language does not have unsigned arithmetic as part of 
its foundation classes, it was necessary to develop 
some simple efficient algorithms for addition and com- 
parison of addresses. The Address abstract class is 
abstract mainly because it is most efficient to use differ- 
ent algorithms for unsigned arithmetic, depending upon 
the number of bits used to represent the address value. 
There are two sub-classes, Address32 for addresses 
up to 32 bits, and Address64 l for addresses up to 64- 
bits. 

Platform Dependance and Platform Independence 

[0046] When a bus manager constructs any of the 
Memory and DMA classes, it must provide a base 
Address and a length (also represented as an 
Address), To do this, it must first construct each of these 
Address objects, and doing so requires knowing the 
number of bits for that the specific type of address on 
the specific platform (platform specific information bus 
managers do know). 

[0047] Drivers, on the other hand, always access 
AccessibleMemory objects that have been constructed 
by bus mangers, and drivers always do so by providing 
an offset from the base of the AccessibleMemory 
object. So that drivers can be readily independent of 
platform specifics, such as the number of bits in a par- 
ticular address, each memory access method of Acces- 
sibleMemory specifies the offset as an int. This allows 
memory objects up to 2 gigabytes. Although no pres- 
ently known platform makes use of larger memory 
objects, methods can easily be added to the class to 
achieve even larger memory objects. 

Representation of Virtual Addresses to the Micro- 
kernel 

[0043] For simplicity, once an address is passed to the 
microkernel, it is represented (in native methods) simply 
as a 64-bit unsigned integer (for the value). 

VirtualAddressSpace Class 

[0049] Some of the machines that utilize the invention 
may have MMUs, so it is desirable to support multiple 
virtual address spaces, which allows there to be multi- 
ple virtual machines. With some prior art systems, appli- 
cations always access memory in the same virtual 
address space as that of the drivers. But, with multiple 
virtual machines supported running in multiple address 
spaces, sometimes an application will be in a different 
address space from its driver. That is, a given driver will 
be accessing a memory object and will have synchroni- 
zation methods for such access to handle the possibility 
of multiple threads of the same virtual machine running 
in that driver simultaneously. Since the virtual machines 



do not have efficient mechanisms for communication 
that could be used to provide synchronization for 
instances of the same driver running in separate virtual 
machines, but possibly accessing the same underlying 

5 memory object (say a register that is mapped in for 
both), it follows that a particular driver will probably 
always be in the same virtual address space, while 
applications that use that driver may be in different 
address spaces. 

10 [0050] To address the above considerations, a 
VirtualAddressSpace class is provided as part of the 
Memory and DMA Classes, and it has a single static 
method, getVaslDQ, for obtaining the virtual address 
space ID of the currently running thread. This ID is 

is obtained from the microkernel. For efficiency, it is 
cached by getVaslDO, so the microkernel does not have 
to be called upon each time. 

Use of Virtual Address Space ID 

20 

[0051] When VirtualMemory objects are constructed, 
the virtual address space ID is one of the parameters of 
the constructor. This ID is eventually provided to the 
microkernel when the microkernel is requested to map 
25 the virtual memory. It follows that only the microkernel 
assigns semantics to the value of the virtual address 
space ID. 

Device Interface Classes 

30 

[0052] The material belcw describes classes 50 which 
constitute a first package of data types, including mem- 
ory classes. These classes are platform independent 
and can thus be imported by platform-independent Java 

35 programming language code of the operating system, 
such as drivers, thereby providing fully functional plat- 
form-independent drivers. Also, since they are platform- 
independent, these classes do not depend upon any of 
the platform-dependent memory classes 72 (Fig. 2). 

40 [0053] For each class, all public fields are docu- 
mented. 

Address 

45 [0054] 

public abstract class Address 

[0055] All memory objects of the Memory and DMA 
so classes use Address objects for their addresses. Since 
there are some actual significant examples of hardware 
which has addresses with non-power-of-two number of 
bits, addresses of any number of bits between 1 and 64 
are supported. As the Address class is abstract, it is 
55 extended by 

Address32, which provides support for addresses 
between 1 and 32 bits, and 
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Address64, which provides support for addresses 
between 33 and 64 bits. 

The Address class defines public abstract methods 
which are implemented by Address32 and Address64: 

public abstract String toStringO ; 
public abstract int intvalue(); 
public abstract long longValueO; 

[0056] In addition to the protected constructor and 
public methods specified below, which are common to 
both sub-classes, the Address abstract class also 
implements a package private method for checking 
whether or not two Addresses are of the same type 
(same number of bits). 

Address 

[0057] 



[0058] 



addAddr 



[0059] 



20 



protected Address (int bits) 

The Address class itself only keeps track of the 
number of bits. The value of the address is stored in 
the sub-class. 25 

getBit Width 



public int getBitwidth() 

Returns: 

The number of bits (between 1 and 64) of this 
address. 



public Address addAddr(Address other) throws to 
Invalid AddressException; 

Parameters : 

other - The Address to add to this Address. 



Returns: 

An Address whose value is the sum of this Address 
and the other Address, and which has the same 
number of bits as both this Address and the other 
Address. 



Throws: 

InvalidAddressException is thrown if the other 
Address does not have the same number of bits as 
this Address, or if the unsigned sum of the values of 55 
both Addresses overflows the maximum unsigned 
value than can he represented with the number of 
bits common to these two Addreses. 



[0060] This method is included for completeness, so 
that a client can form an Address which is the sum of a 
base Address and an offset (also represented as an 
Address), without the client having to implement its own 

5 algorithms for unsigned arithmetic. However, since cli- 
ents always access (read or write) memory objects by 
specifying only an offset, leaving the Memory classes to 
compute the address of access (sum of the base 
Address and offset), the clients should not really need to 

w use this method. 

[0061 ] This method invokes the appropriate method of 
the underlying Address sub-class. 

addrCompare 

75 

[0062] 

public int addrCompare(Address other) throws 
InvalidAddressException; 

Parameters: 

other - The Address to compare with this address. 

Returns: 

-1 if the value of this Address is greater than the 
value of the other Address. 
0- if the value of this Address is equal to the value 
of the other Address. 

-1 - if the value of this Address is less than the value 
30 of the other Address. 

Throws: 

InvalidAddressException is thrown if the other 
Address does not have the same number of bits as 
35 this Address. 

[0063] Clients access (read or write) a memory object 
by specifying an offset (also represented as an 
Address). This method allows a client to determine 
whether this offset is valid (less than the length of the 
memory object), without having to implement its own 
algorithms for unsigned arithmetic. However, it is not 
absolutely necessary that the client use this method, 
since the Memory class access methods already do 
45 bounds checking. 

[0064] This method invokes the appropriate method of 
the underlying Address sub-class. 

Address 3 2 

[0065] 

public class Address32 extends Address 

[0066] The Address32 class extends the abstract 
Address class, and provides support for addresses 
whose number of bits is between 1 and 32, inclusive. 
The public methods specified here consist of construc- 
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tion methods and implementations of abstract public 
methods of the Address abstract class. 
[0067] It should be noted that the Address32 class 
also implements package private methods for unsigned 
32-bit addition and unsigned 32-bit comparison, which 
are more efficient for internal calculations than the pub- 
lic methods, addAddr() and addrCompare() of the 
Address class. These package-private methods are 
more efficient because they do not have to allocate the 
Address object to return. 

Address32 

[0068] 

public Address32(int addrvalue, int bitwidth) throws 
InvalidAddressException 

public Address32(int addrvalue) 

public Address32(long addrvalue, int bitwidth) 
throws InvalidAddressException 

Parameters: 

addrvalue - The actual value of the Address. If 
bitwidth is specified, and it is less than 32, only the 
least significant bitwidth number of bits is used for 
the value of the Address. 

bitwidth - The number of bits (between 1 and 32) of 
the Address. 

Throws: 

Invalid Address Exception is throws if a bitwidth is 
specified which is not between 1 and 32, inclusive. 

[0069] The first of these constructors allows the client 
to create a general type of address of between 1 and 32 
bits. The second constructor is provided for conven- 
ience to construct the more common 32-bit Address. 
The third constructor is provided for convenience, when 
the value for the Address is a long. In this case, though, 
only the least significant 32-bits (or less) are used. 

to String 

[0070] 

public String to String() 
Returns: 

A string representing this Address32 object. 

intValue 

[0071] 

public int intvalue() 
Returns: 

The least significant 32 bits of the address value. 



long Value 
[0072] 

5 public long Value() 
Returns: 

The least significant 64 bits of the address value. 
io Address64 
[0073] 

public class Address 64 extends Address 

15 

[0074] The Address64 class extends the abstract 
Address class, and provides support for addresses 
whose number of bits is between 33 and 64, inclusive. 
The public methods specified here consist of construc- 

20 tion methods and implementations of abstract public 
methods of the Address abstract class. 
[0075] It should be noted that the Address64 class 
also implements package private methods for unsigned 
64-bit addition and unsigned 64-bit comparison, which 

25 are more efficient for internal calculations than the pub- 
lic methods, addAddr() and addrCompare() of the 
Address class. These package-private methods are 
more efficient because they do not have to allocate the 
Address object to return. 

30 

Address64. 
[0076] 

35 public Address64(long addrvalue, int bitwidth) 
throws InvalidAddressException 

public Address64(long addrvalue) 

40 Parameters: 

addrvalue - The actual value of the Address. If 
bitwidth is specified, and it is less than 64. only the 
least significant bitwidth number of bits is used for 
the value of the Address. 

45 bitwidth - The number of bits (between 33 and 64) 
of the Address. 

Throws: 

InvalidAddressException is throws if a bitwidth is 
so specified which is not between 33 and 64, inclusive. 

[0077] The first of these constructors allows the client 
to create a general type of address of between 33 and 
64 bits. The second constructor is provided for conven- 
55 ience to construct the more common 64-bit Address. 
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toString 
[0078] 



public StringtoString 
Returns: 

A string representing this Address64 object. 



intValue 
[0079] 



public int intvalue() 

Returns: 

The least significant 32 bits of the address value. 



longValue 
[0080] 

public long longvalueO 

Returns: 

The least significant 64 bits of the address value. 
AddressSpace 
[0081] 

public abstract class AddressSpace 

[0082] Every bus manager manages a set of address 
spaces. The memory classes themselves have three 
address spaces (see VirtualAddressSpace. Physica- 
lAddressSpace. and DMAAddressSpace) which are all 
logically part of the particular bus manager known as 
the PlatformBusManager, the highest level bus man- 
ager. Besides these address spaces, there are other 
address spaces that other bus managers can instanti- 
ate. All such address spaces are sub-classes of the 
AddressSpace abstract class. 

AddressSpace 

[0083] 

protected AddressSpace (ExpansionBus b, String 
n) 

Parameters: 

b - Specifies the bus that has this particulars 
address space. 

n-A string naming this address space. 

[0084] This constructor simply initializes protected 

variables with the supplied values. 

[0085] A protected initialization routine is also pro- 



70 



35 



40 



vided so that the sub-class can initialize the bit-size of 
the address space and an id for the address space. 
Both of these initializers might be obtained by the sub- 
class via native methods. In the case where there may 
be multiple address spaces of a particular type (e.g. vir- 
tual), the id obtained from the microkernel uniquely 
specifies one, so that it can be specifically identified. 
Using the initializer for the number of bits of the address 
space, the AddressSpace class computes and stores 
Address objects representing the lowest and highest 
possible addresses. 



getID 
75 [0086] 

public int getlD() 
Returns: 

20 The id that specifies which particular address 
space (see above). 

getName 

25 [0087] 

public String getName() 
Returns: 

The String used to initialize this address space in 
30 the constructor. 

getExpansionBus 

[0088] 



public String getName() 
Returns: 

The bus used to initialize this address space in the 
constructor. 



getLowestAddress 
[0089] 

45 public String getLowestAddressO 
Returns: 

The lowest address value possible in this address 
space. 

50 

g et H i g hest Add ress 
[0090] 

55 public String getHighestAddressO 
Returns: 

The highest address value possible in this address 
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space. 



MemoryConstraints 

[0091] 5 

public class MemoryConstraints 

[0092] When a bus manager creates a memory 
object, it may need to specify constrains of both the alio- 10 
cation of the memory object, and subsequent accesses 
to the memory object by a driver. For example, some 
DMA controllers may have a limited range of addresses 
they can emit, thus necessitating that a DMA object (a 
memory object) be allocated only in that address range. 15 
As an example of access constraints, some registers 
may only be accessible as bytes, such that any other 
access may cause some sort of system failure. 
[0093] The MemoryConstraints object encapsulates 
such allocation and access constraints, so that they can 20 
be passed together to a constructor of a memory object. 
[0094] The MemoryConstraints class contains a con- 
structor used to specify all the various constraints, and 
several methods for obtaining and setting each of the 
various constraints. This class also contains package 25 
private methods for checking whether a requested 
access satisfies the constraints, and whether a speci- 
fied allocation matches the constraints. 
[0095] The following constants are defined: 

30 

public static final int ALIGN_BYTE = 0; 

public static final int ALIGN_SHORT = 1 ; 

public static final int ALIGN J NT = 2; 

public static final int ALIGN_LONG = 3; 

public static final int ALIGN_CACHE = 4; 35 

public static final int ALIGN_PAGE = 5; 

public static final int READONLY = 0; 

public static final int READWRITE = 1 ; 



MemoryConstraints 



[0096] 



40 



public MemoryConstraints (Address alloc_min_a, 
Address altoc_max_a, int alloc_aIign, int cache, 45 
boolean lock, boolean waitformem, boolean 
swapped, boolean io, boolean virtual, int 
access_min_s, int access_max_s, int 
access_align, int rw) throws InvalidAddressExcep- 
tion so 

Parameters: 

alloc_min_a - The minimum address for allocation. 
alloc_max_a - The maximum address for alloca- 
tion. 55 
alloc_align - The minimum number of least signifi- 
cant bits of the base address of an allocation that 
must be all OS. A value of 0 thus indicates there are 



no alignment constraints for allocations. The maxi- 
mum value supported of alloc_align is 16 (64K byte 
alignment). 

cache - Indicates caching of the memory (either 
MainMemory.CACHE_MODE_DEFAULT, 
MainMemory.CACHE_MODEJNHIBITED.Main- 
Memory.CACHE_MODE_WRIT E_ THROUGH, 
MainMemory.CACHE_MODE_COPY_BACK). 
lock - Indicates whether or not the mappings for the 
memory are to be locked. 

swapped - If true, indicates a type of memory is to 
be constructed, where byte-swapping is to be done, 
io - If true, indicates a type of memory is to be con- 
structed that is I/O memory (either PortlOMemory 
or VirtuallOMemory). 

virtual - If true, indicates a type of memory is to be 
constructed that is VirtualMemof y 
waitformem - Indicates whether or not to wait indef- 
initely for the allocation of the memory, rf there is a 

resource problem. 

access_min_s- The log (base2) of the minimum 
size in bytes of memcxy that can be accessed. 
Thus. 0 indicates that a single byte can be 

accessed. 

access_max_s - The tog (base 2) of the maximum 
size in bytes of memory that can be accessed (up to 

3)- 

access_align - The mrvmjm number of least signif- 
icant bits of an access address that must be all Os. 
A value of 0 thus indicates thai the* e are no align- 
ment constraints for accesses The maximum value 
supported of access_al^n cs 16 (64K byte align- 
ment). 

rw - READONLY (0) ndcates reaa-onJy access, 
while READWRITE(i) indicates read-write access. 

Throve: 

InvahcAddressException rs thrown rf alloc_min_a 
and ailoc_max_a do not agee on their number of 
bits, or if the value ol ai*oc_mn_a is net less than 
the value of alloc_mar_a 

[0097] Tne maximum see allocation alignment sup- 
ported is ALIGN_PAGE (5). and the mmmum is. of 
course, ALIGN_BYTE(0). so if the specified alloc_align 
is greater than ALIGN_PAGE (5). f. is set to 5. or if the 
specified alloc_align is less than ALK3N_BYTE(0), it is 
set to 0. 

[0098] rf the specified access_mn_s is less than 0, it 
is set to 0 (1 byte), or if the specrfted access_minds is 
greater than 3, it is set to 3 (8 bytes, a tong) Similarly, if 
the specified access_max_s is less than 0. it is set to 0 
(1 byte), or if the specified access_max_s is greater 
than 3, it is set to 3 (8 bytes, a long) If access_max_a is 
still less than access_min_a. access_max_a is set to 
the value of access_min_a. 

[0099] The maximum size access alignment sup- 
ported is ALIGN_LONG(3). and the minimum sup- 



21 



EP 0 953 899 A2 



22 



ported is, of course, ALIGN_BYTE(oy; so if the specified 
access_align is greater than ALIGN_LONG(3), it is set 
to 3, or if the specified access_align is less than 
ALIGN_BYTE(0), it is set to 0. 
[0100] If rw is not set to READONLY, it is set to READ- 
WRITE. 

getAllocMinAddr 
[0101] 

public Address getAllocMinAddrO 

Returns: 

The minimum allocation Address, alloc_min_a, 
which was specified by either the constructor, or by 
the setAllocAddrsO method. 

getAllocMaxAddr 

[0102] 

public Address getAllocMaxAddr() 

Returns: 

The maximum allocation Address, alloc_max_a. 
which was specified by either the constructor, or by 
the setAllocAddrsO method. 

setAllocAddrs 

[0103] 

public void setAllocAddrs(Address alloc_min_a, 
Address alloc__max_a) throws InvalidAddressEx- 
ception 

Parameters: 

alloc_mill_a - The minimum address for allocation. 
alloc_max_a - The maximum address for alloca- 
tion. 

Throws: 

InvalidAddressException is thrown if alloc_min_a 
and aIloc_max_a do not agree on their number of 
bits, or if the value of alloc_mill_a is not less than 
the value of alloc_max_a. 

get Alloc Align 

[0104] 

public int getAllocAlign() 
Returns: 

The alignment for allocations. alloc_align, as speci- 
fied by either the constructor, or by the setAllocAI- 
lign() 

method. Note that this value may be different from 



the value specified (see descriptions of the con- 
structor or the setAllocAlign method). 

setAllocAlign 

5 

[0105] 

public void setAllocAlign(int alloc_align) 

10 Parameters: 

alloc_align - The minimum number of least signifi- 
cant bits of the base address of an allocation that 
must be all 0s. A value of 0 thus indicates there are 
no alignment constraints for allocations. The maxi- 

15 mum value supported of alloc_align is 16 (64K byte 
alignment). 

[0106] The maximum size allocation alignment sup- 
ported is ALIGN_PAGE (5), and the mimimum is, of 
so course, ALIGN_BYTE(0) ( so if the specified alloc_a!ign 
is greater than ALIGN_PAGE (5), it is set to 5, or if the 
specified alloc_align is less than ALIGN_BYTE(0), it is 
set to 0. 

25 getCacheMode 

[0107] 

public int getCacheMode() 
30 Returns: 

The cache mode, cache, as specified by either the 
constructor, or by the setMiscAlloc() method, 

getLocked 

35 

[0108] 

public boolean getLockedQ 

40 Returns: 

The indication of whether mappings are to be 
locked upon allocation, lock, as specified by either 
the constructor, or by the setMiscAlloc() method. 

45 getWaitforMen 

[0109] 

public boolean getwaitFormMemO 

50 

Returns: 

The indication of whether or not to wait for memory 
indefinitely during allocation, waitformem, as speci- 
fied by either the constructor, or by the setMiscAI- 
55 locO method. 
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[0110] 

public int getSwappedO 5 

Returns: 

The argument, swapped, as specified by either the 
constructor, or by the setMiscAllocQ method. 

getIO 10 



[0111] 

public intgetlO() 

Returns: 

The argument, io. as specified by either the con- 
structor, or by the setMiscAlloc() method. 

getVirtuai 

[0112] 

public int getVirtua!() 

Returns: 

The argument, virtual, as specified by either the 
constructor, or by the setMiscAlloc() method. 

setMiscAlloc 

[0113] 

public void setMiscAllocfmt cache, boolean lock, 
boolean waitformem, boolean swapped, boolean io, 
boolean virtual) 
Parameters: 

cache - indicates caching of the memory (either 
Mai nMemory.CACHE_MODE_DE FAULT, Main- 
Memory.CACHE MODEJNHIBITED, MainMemory. 
CACHE_MODE WRITE_THROUGH, or MainMem- 
ory. CACHE_MODE_COPY_BACK). 
lock - Indicates whether or not the mappings for the 
memory are to be locked. 

waitformem - Indicates whether or not to wait indef- 
initely for the allocation of the memory, if there is a 
resource problem. 

swapped - If true, indicates a type of memory is to 
be constructed, where byte-swapping is to be done, 
io - If true, indicates a type of memory is to be con- 
structed that is I/O memory (either PortlOMemory 
or Virtual lOMemory). 

virtual - if true, indicates a type of memory is to be 
constructed that is VirtualMemory. 



[0114] 

public int getAccessMinSize() 

Returns: 

The minimum size for accesses, access_min_s, as 
specified by either the constructor, or by the setAc- 
cessSizesO method. Note that this value may be 
different from the value specified (see descriptions 
of the constructor or the setAccessSizes() method). 

getAccessMaxSize 

15 

public int getAccessMaxSizeO 

[0115] 

20 Returns: 

The maximum size for accesses, access_max_s, 
as specified by either the constructor, or by the 
setAccessSizesO method. Note that this value may 
be different from the value specified (see descrip- 
25 tions of the constructor or the setAccessSizesO 
method). 

setAccessSizes 

30 [0116] 

public void setAccessSizes(int access_min_s, int 
access_max_s) 

35 Parameters: 

access_min_s-The log (base 2) of the minimum 
size in bytes of memory that can be accessed. 
Thus, 0 indicates that a single byte can be 
accessed. 

40 access_max_s - The log (base 2) of the maximum 
size in bytes of memory that can be accessed(up to 
3). 

[01 17] If the specified access_min_s is less than 0, it 
45 is set to 0 (1 byte), or if the specified access_jnin_s is 
greater than 3, it is set to 3 (8 bytes, a long). Similarly, if 
the specified access_max_s is less than 0, it is set to 0 
(1 byte), or if the specified accessjnax_s is greater 
than 3, it is set to 3 (8 bytes, a long). If access_max_a is 
so still less than access_min_a, access_max_a is set to 
the value of access_min_a. 

getAccessAHgn 

55 [0118] 



25 



30 



35 



40 



45 



50 



public void getAccessAlignQ 
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Returns: 

The alignment for accesses, access_align, as spec- 
ified by either the constructor, or by the setAcces- 
sAlign() method. Note that this value may be 
different from the value specified (see descriptions 
of the constructor or the setAccessAlign method). 

setAccessAlign 

[0119] 

public void setAccessAlign(int access_align) 
Parameters: 

access_align - The minimum number of least signif- 
icant bits of an access address that must be all 0s. 
A value of 0 thus indicates that there are no align- 
ment constraints for accesses. The maximum value 
supported of access_align is 16 (64K byte align- 
ment). 

[0120] The maximum size access alignment sup- 
ported is ALIGN_LONG(3), and the minimum sup- 
ported is, of course. ALIGN_BYTE(0), so if the specified 
access_align is greater than ALIGN_LONG(3), it is set 
to 3, or if the specified access_align is less than 
ALIGN_BYTE(0). it is set to 0. 

get Read Write 

[0121] 

public int getReadwrite() 

Returns: 

The mode of access, either READONLY, or READ- 
WRITE. Note that this value may be different from 
the value specified (see descriptions of the con- 
structor or the setReadWrite method). 

setReadWrite 

[0122] 

public void setReadwrite(int rw) 
Parameters: 

rw - READONLY indicates read-only access, while 
READWRITE indicates readwrite access. 

[0123] If rw is not set to READONLY, it is set to READ- 
WRITE. 

Memory 

[0124] 

public abstract class Memory 



[0125] All memory objects of the Memory and DMA 
classes are ultimately sub-classes of the abstract class 
Memory. The Memory abstract class defines two 
abstract methods: 

5 

public abstract String toString(); 

[01 26] In addition to the fundamental public methods 
specif ied below that are common to all memory objects, 

10 the Memory class also implements package private 
methods for checking validity of an access (specified by 
offset within a memory object, size, mode (read or 
write), and count in bytes), and for obtaining the 
address of an access, given an offset of the memory 

15 object. 

Memory 
[0127] 

20 

protected Memory (Address ba. Address len, Mem- 
oryConstraints mc) throws IrvaldAddressExcep- 
tion 

25 protected Memory () 

protected Memory (Memory superrange. Address 
offset, Address len) throvs In/aldAddressExcep- 

tion, AllocationExcepfon 

Parameters: 

ba - The base Address of the Memory object, 
len - The length in bytes of trie Memory object, 
mc - Constraints of the memory object 

Throws: 

InvalidAddressException is thrown if an overflow 
occurs when adding the base AdrJess. ba. to the 
length, len. 

40 AIlocationException is thrown, in me case of the 
third protected constructor, rl the super-range Mem- 
ory object is invalid. 

[0128] This first protected conductor simply calcu- 
45 lates the end Address (ba + len). saves al the parame- 
ters, along with the calculated end Address n protected 
variables of this class, initializes the memory to valid, 
and allocates protected internal data structures. 
[0129] The second protected constructor ts used in 
so the case where the underlying Memory object cannot 
be initialized when first constructed (e g VirtualMemory 
whose base address will not be known until the memory 
has been mapped in). A protected method is provided 
for later initializing the Memory object, thus completing 
55 what would have been initialized had the first protected 
constructor been used. 

[01 30] The third protected constructor is used in the 
case where the memory object being constructed is a 
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sub-range of an existing memory object. The memory 
base Address and end Address are calculated based 
upon the offset to the superrange Memory object, and 
the new Memory object is associated as a sub-range of 
the superrange and initialized to valid. Protected inter- 
nal data structures area also allocated. 

getMemBaseAddr 

[0131] 

public Address getMemBaseAddrQ 
Returns: 

The base Address of the Memory object if the 
memory is valid, and null otherwise. 

getMem Length 

[0132] 

public Address getMeml_ength() 
Returns: 

The length of the Memory object in bytes if the 
memory is valid, and null otherwise. 



TO 



getSuperRange 
[0136] 

public Memory getSuperRange() 
Returns: 

The Memory object which is a super-range of this 
Memory object, if it is a sub-range; otherwise 
returns null. 

getSubRanges 



[01 37] 

75 public Vector getSubRanges() 
Returns: 

The a Vector of Memory objsts which are sub- 
ranges of this Memory object. If there are no sub- 
20 ranges or if this Memory object is invalid, null is 
returned. 

Memory Descriptor 

25 [01 38] ; 



getMemEndAddr 



public class MemoryDescriptor extends Memory 



[0133] 

30 

public Address getMemEndAddr () 
Returns: 

The end Address of the Memory object if the mem- 
ory is valid, and null otherwise. 35 

getMemValid 

[0134] 

40 

public boolean getMemvalid() 
Returns: 

The indication of whether or not the memory is 
valid. 45 

getMemConstraints 
[0135] 

50 

public MemoryConstraints getMemConstraints () 



[0139] All reaJ instantiated memory objects are ulti- 
mately platform-dependent and are thus constructed by 
code in the sunjavaos. memory package. Sometimes, 
though, it is useful for drivers or bus managers to be 
able to instantiate a memory object, which is a descrip- 
tor for memory that will be allocated later. The Memory- 
Descriptor class, as an instantiate sub-class of 
Memory, meets that need. 

[0140] Associated with a MemoryDescriptor object is 
an address space, managed by some bus manager, 
within which this descriptor of memory is defined. 

MemoryDescriptor 

[0141] 

public MemoryDescriptor(Address ba, Address len, 
MemoryConstraints mc, AddressSpace as, String 
name) throws InvalidAddressException 

public MemoryDescriptor(Address ba, Address len, 
AddressSpace as, String name) throws InvalidAd- 
dressException 

Parameters: 

ba - The base Address of the Memory object, 
len - The length in bytes of the Memory object, 
mc - Constraints of the memory object, 
as • The AddressSpace in which this memory 
object lives. 



Returns: 

The constraints of the memory if the memory is 
valid, otherwise null. 55 
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name • Some name that is used to identify this 
memory object. This is useful when a bus manager 
is allocating an array of MemoryDescriptors, speci- 
fying ali the various memory objects that a driver 
needs to have mapped, since it allows the driver to 
identify each of the memory objects. 

Throws: 

InvalidAddressException is thrown if the construc- 
tor of the super-class (Memory) throws InvalidAd- 
dressException. In other words, this constructor 
does not catch that exception. 

[0142] The first constructor simply calls the construc- 
tor of the super-class, Memory, using all but the 
AddressSpace argument, and then stores the 
AddressSpace in a private variable. 
[0143] The second constructor is provided for conven- 
ience, and is the same as the first constructor, except 
that null is passed to. the Memory constructor for the mc 
(MemoryConstraints) parameter. 

toString 

[0144] 

public String toString() 
Returns: 

A string representing this MemoryDescriptor object. 
getAddressSpace 
[0145] 

public AddressSpace getAddressSpace () 
Returns: 

The AddressSpace in which this descriptor of Mem- 
ory exists, as specified in the constructor. 

getName 

[0146] 

public String getNameO 

Returns: 

The string naming this particular MemoryDescrip- 
tor. as specified in the constructor. 

Ma in Memory 

[0147] 

public abstract class MainMemory extends Memory 
[0148] Ail memory objects which represent memory 



that can be accessed ultimately by a CPU (everything 
except DMAMemory, the already described super-class 
Memory, and MainMemory itself) is a sub-class of the 
abstract class, MainMemory. 
5 [0149] MainMemory defines the following abstract 
methods: 

public abstract void setCacheMode(int mode); 

10 public abstract int getCacheMode(); 

public abstract void flushCache(); 

[0150] MainMemory also defines the following con- 
15 stants to be used as parameters for implementations of 
setCacheModeO and return values of implementations 
of getCacheModeO: 

public static final int 

20 C AC H E_MO D E_D E FAU LT=0x0 ; 

public static final int 

CACHE JUODE_AMBIGUOUS=0x1 ; 

25 public static final int 

CACHE_MODE_INHIBITED=0x2: 

public static final int 

CACHE_MODE_WRITE_THROUGH=0x3; 

30 

public static final int 

CACHE_MODE_COPY_BACK=0x4; 

[0151] The only methods implemented for this class 
35 are protected constructors. No public methods are 
implemented. 

MainMemory 

40 [0152] 

protected MainMemory (Address ba, Address len, 
MemoryConstraints mc) throws InvalidAddressEx- 
ception 

45 

protected MainMemory 0 

protected MainMemory (MainMemory superrange, 
Address offset.Address len)throws invalidAd- 
50 dressException, AllocationException 

Parameters: 

ba - The base Address of the Memory object, 
len - The length in bytes of the Memory object. 
55 mc - Constraints of the memory object. 

Throws: 

InvalidAddressException is thrown if an overflow 



31 EPOS 

y 

occurs when adding the base Address, ba, to the 
length, len. 

AIlocationException is thrown, in the case of the 
third protected constructor, if the super-range Mem- 
ory object is invalid. 

[01 53] Each of these protected constructors simply 
calls the corresponding protected constructor of the 
super-class, Memory. 

AccessibleMemory 

[0154] 

public abstract class AccessibleMemory extends 
MainMemory 

[0155] All memory objects of the Memory and DMA 
classes which represent memory that can be accessed 
directly by a CPU (every sub-class of MainMemory 
except PhysicalMemdry and AccessibleMemory itself) 
is a sub-class of the abstract class, AccessibleMemory. 
[0156] Platform-independent code, such as drivers, 
always access Memory via the methods of Accessible- 
Memory, not knowing or caring what the underlying 
memory object may be. 

[0157] AccessibleMemory defines the following pro- 
tected abstract methods, which are internal implemen- 
tations of the publicly defined access methods: 

protected abstract irrt ncksum(long adr, long len); 

protected abstract void nSetByte(long adr, byte x); 

protected abstract void nSetShort(long adr, short 

x); 

protected abstract void rSetlnt(long adr, int x); 

protected abstract void nsetLong(long adr, long x); 

protected abstract void nSetBytes(long adr, byte 
bytesQ.int bytesOffset, int length); 

protected abstract void nsetlntArray(long adr, byte 
bytesD.int bytesOffset, int lengthjnt); 

protected abstract byte nGetByte(long adr); 

protected abstract short nGetShort(long adr); 
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protected abstract void nGetlntArray(lorg adr, byte 
bytesQjnt bytesOffset. int lengthjnt); 

protected abstract int nRegisterSource(long adrl, 
5 long len); 

protected abstract void nCopy(long adr2, long len, 
int copy ID); 

10 [0158] There are no other non-public methods 
defined, besides the constructor. 
[01 59] AccessibleMemory does not implement any of 
the abstract methods of the two classes above it in the 
hierarchy, MainMemory and Memory. 

is [0160] It should be noted that each of the access 
methods below checks for invalid accesses, and if there 
is a violation, a system message is logged, and the 
access is not performed. The reason for not simply hav- 
ing these methods throw an exception is that then all 

20 current calls in various drivers - and there are very many 
- would need to be modified to declare the exception 
thrown, when drivers are ported to the new Memory 
classes. 

25 AccessibleMemory 

[0161] 

protected AccessibleMemory(Address ba, Address 
30 len, MemoryConstraints mc) throws InvalidAd- 
dressException 

protected AccessibleMemory () 

35 protected AccessibleMemory (AccessibleMemory 
superrange, Address offset, Address len) throws 
InvaiidAddressException, AIlocationException 

Parameters: 

40 ba - The base Address of the Memory coject. 
len - The length in bytes of the Memory object, 
mc - Constraints of the Memory object. 

Throws: 

45 InvaiidAddressException is thrown if an overflow 
occurs when adding the base Address, ba, to the 
length, len. 

AIlocationException is thrown, in the case of the 
third protected constructor, if the super-range Mem- 
50 ory object is invalid. 



protected abstract int nGetlnt(long adr); 

protected abstract long nGetl_ong(long adr); 

protected abstract void nGetBytes(long adr, byte 
bytesQ.int bytesOffset, int length); 



[01 62] Each of these protected constructors simply 
calls the corresponding protected constructor of the 
super-class. MainMemory. 
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setAddress 



[0163] 



public void setAddress(int offset, Address value) 
Parameters: 

■offset - Offset from the base of the memory object 
to the place where the access (in this case a write) 
is to be done. 

value - The Address whose value is to be written at 
the access location. 



The access is not done and a system message is 
logged if the memory is not valid (defined in Mem- 
ory class), if the offset (plus size of access) is 
beyond the end of the memory object, or if any of 
the constraints defined in the constraints of the 
super-class Memory object is violated. 



setShort 



10 [0166] 



public void setShort(int offset, short x) 



Note: 

The access is not done and a system message is 
logged if the memory is not valid (defined in Mem- 
ory class), if the offset (plus size of access) is 
beyond the end of the memory object, or if any of 
the constraints defined in the constraints of the 
super-class Memory object is violated. 

cksum 

[0164] 

public int cksum(int offset, int len) 

Parameters: 

offset - Offset from the base of the memory object 
to the place where the checksum computation is to 
start. 

len - The length in bytes over which the checksum 
is.to be computed. 



Parameters: 

is offset - Offset from the base of the memory object 
to the place where the access (in this case a write) 
is to be done. 

x - The value to be written at the access location. 

20 

Note: 

The access is not done and a system message is 
logged if the memory is not valid (defined in Mem- 
ory class), if the offset (plus size of access) is 
25 beyond the end of the memory object, or if any of 
the constraints defined in the constraints of the 
super-class Memory object is violated. 

setlnt 

30 

[0167] 

public void setlnt(int offset, int x) 



Returns: 

The computed checksum (modulo 0x10000), or 0 if 
the access is not allowed (see Note). 

Note: 

The checksum is not done (but 0 is returned) and a 
system message is logged if the memory is not 
valid (defined in Memory class), or if the offset (plus 
length, len, of access) is beyond the end of the 
memory object. 

setByte 

[0165] 

public void setByte(int offset, byte x) 

Parameters: 

offset - Offset from the base of the memory object 
to the place where the access (in this case a write) 
is to be done. 

x - The value to be written at the access location. 

Note: 



35 Parameters: 

offset * Offset from the base of the memory object 
to the place where the access (in this case a wire) 
is to be done. 

x - The value to be written at the access location. 

40 

Note: 

The access is not done and a system message is 
logged if the memory is not valid (defined in Mem- 
ory class), if the offset (plus size of access) is 
45 beyond the end of the memory object, or if any of 
the constraints defined in the constraints of the 
super-ass Memory object is violated. 

setLong 

50 

[0168] 

public void setLong(int offset, long x) 

55 Parameters: 

offset - Offset from the base of the memory object 
to the place where the access (in this case a write) 
is to be done. 
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x - The value to be written at the access location. 

Note: 

The access is not done and a system message is 
logged if the memory is not valid (defined in Mem- 
ory class), if the offset (plus size of access) is 
beyond the end of the memory object, or if any of 
the constraints defined in the constraints of the 
super-class Memory object is violated. 

setBytes 

[0169] 

public void setBytes(int offset, byte bytesQ, int 
bytesOffset, int length) 

Parameters: 

offset - Offset from the base of the memory object 
to the place where the access (in this case a write) 
is to be done. 

bytes - The array of bytes to be written to the mem- 
ory. 

bytesOffset - The index within the array, bytes, to 
begin. 

length • The number of bytes to write. 

Note: 

The access is not done and a system message is 
logged if the memory is not valid (defined in Mem- 
ory class), if bytesOffset is negative, if length is not 
greater than 0, if the offset (plus total size of 
access) is beyond the end of the memory object, or 
if any of the constraints defined in the constraints of 
the super-class Memory object is violated. 

setlntArray 



[0170] 



public void setlntArray(int offset, byte bytesQ, int 
bytesOffset, int iengthjnt) 

Parameters: 

offset - Offset from the base of the memory object 
to the place where the access (in this case a write) 
is to be done. 

bytes - The array of bytes to be written (as integers) 
to the memory. 

bytesOffset - The index within the array bytes to 

begin, 

Iengthjnt - The number of ints to write. 
Note: 

The access is not done and a system message is 
logged if the memory is not valid (defined in Mem- 
ory class), rf bytesOffset is negative, if Iengthjnt is 
not greater than 0, if the offset (plus total sire of 
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access) is beyond the end of the memory object, or 
if any of the constraints defined in the constraints of 
the super -class Memory object is violated. 

getByte 
[0171] 

public byte getByte(int offset) 

Parameters: 

offset - Offset from the base of the memory object 
to the place where the access (in this case a read) 
is to be done. 

Returns: 

The value read from the access location. 
Note: 

The access is not done and a system message is 
logged if the memory is not valid (defined in Mem- 
ory class), if the offset (plus size of access) is 
beyond the end of the memory object, or if any of 
the constraints defined in the constraints of the 
super-ass Memory object is violated. 

getShort 

[0172] 

public short getShort(int offset) 

Parameters: 

offset - Offset from the base of the memory object 
to the place where the access (in this case a read) 
is to be done. 

Returns: 

The value read from the access location. 

Note: 

The access is not done and a system message is 
logged if the memory is not valid (defined in Mem- 
ory class), if the offset (plus size of access) is 
beyond the end of the memory object, or if any of 
the constraints defined in the constraints of the 
super-class Memory object is violated. 

getlnt 



50 



[0173] 



55 



public int getlnt(int offset) 

Parameters: 
offset - Offset 

from the base of the memory object to the place 
where the access (in this case a read) is to be done. 
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Returns: 

The value read from the access location. 

Note: 

The access is not done and a system message is 
logged if the memory is not valid (defined in Mem- 
ory class), if the offset (plus size of access) is 
■beyond the end of the memory object, or if any of 
the constraints defined in the constraints of the 
super-class Memory object is violated. 

getLong 

[0174] 

public long getLong(int offset) 
Parameters: 

offset - Offset from the base of the memory object 
to the place where the access (in this case a read) 
is to be done. 

Returns: 

The value read from the access location. 
Note: 

The access is not done and a system message is 
logged if the memory is not valid (defined in Mem- 
ory class), if the offset (plus size of access) is 
beyond the end of the memory object, or if any of 
the constraints defined in the constraints of the 
super-class Memory object is violated. 

get Bytes 

[0175] 

public void getBytes(int offset, byte bytesO, int 
bytesOffset, int length) 

Parameters: 

offset - Offset from the base of the memory object 
to the place where the access (in this case a read) 
is to be done. 

bytes - The array of bytes to be read from memory. 
bytesOffset - The index within the array bytes to 
begin. 

length - The number of bytes to read. 
Note: 

The access is not done and a system message is 
logged if the memory is not valid (defined in Mem- 
ory class), if bytesOffset is negative, if length is not 
greater than 0, if the offset (plus total size of 
access) is beyond the end of the memory object, or 
if any of the constraints defined in the constraints of 
the super-class Memory object is violated. 



getlntArray 
[0176] 

5 public void get!ntArray(int offset, int intsQ, int 
intsOffset, int lengthjnt) 

Parameters: 

offset * Offset from the base of the memory object 
10 to the place where the access (in this case a read) 
is to be done. 

ints-The array of ints to be written to the memory. 
intsOffset - The index within the array ints to begin. 
lengthjnt-The number of ints to write. 

15 

Note: 

The access is not done and a system message is 
logged if the memory is not valid (defined in Mem- 
ory class), if intsOffset is negative, if lengthjnt is 
20 not greater than 0, if the offset (plus total size of 
access) is beyond the end of the memory object, or 
if any of the constraints defined in the constraints of 
the super-class Memory object is violated. 

25 copy 

[0177] 

public void copy(int offset, AccessibleMemory dest, 
30 int destOffset, int length) 

Parameters: 

offset - Offset from the base of the memory object 
to the place where the access (in this case a read) 
is to be done. 

35 dest - The memory object which contains the desti- 
nation of the copy. 

destOffset - Offset (expressed as either an 
Address, a short, an int, or a long) from the base of 
the memory object to the place where the access 
40 (in this case a write) is to be done. 

Note: 

Tbe access is not done and a system message is 
logged if the memory (either source or destination) 
is not valid (defined in Memory class), if the offset 
45 (plus total size of access for both source and desti- 
nation) is beyond the end of the memory object, if 
any of the constraints defined in the constraints of 
the super-class Memory object is violated, or if the 
two Memory objects are not the same basic type. 

50 

Platform Interface Classes 

[01 78] The material below describes classes 72 which 
constitute a second package of memory classes. Unlike 
55 memory classes 50 which are platform-independent, 
the classes of memory package 72 are platform- 
dependent. These classes are primarily used by plat- 
form-dependent client code of, for example, bus manag- 
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ers. These classes depend upon and extend the 
platform-independent classes of javax.system.memory. 

PhysicalAddressSpace 

5 

[0179] 

public final class PhysicalAddressSpace extends 
AddressSpace 

[0180] The PhysicalAddressSpace is not really used 
by the memory classes themselves, since it is assumed 
that a machine only has one physical address space, 
but it is provided for completeness, and for use outside 
of the memory classes, with a MemoryDescriptor, by is 
various bus managers. 

[0181] Besides the constructor, the following public 
string is defined: 

public final static String name = "physical"; 20 

PhysicalAddressSpace 

[0182] 

25 

public PhysicalAddressSpace (ExpansionBus b) 

[0183] This constructor first calls the constructor of the 
super-class, AddressSpace, specifying the Expansion- 
Bus argument and the String defined above, so that so 
they may be used by the public methods, getExpansion- 
Bus() and getName() of AddressSpace. Then it calls the 
getAddressSize() and the alloc_id() native methods 
(see below) and supplies them to an protected initializa- 
tion routine of AddressSpace, so that they may then be 35 
used by the public methods, getLowestAddress(), 
getHighestAddress(), and getlD() of AddressSpace. 
[0184] The PhysicalAddressSpace defines the follow- 
ing native methods, implemented in the microkernel, 
which provide the size of addresses (in bits) and an ID *o 
for the address space, respectively. 

private native int getAddressSize(); 

private native int alloc_id(); 45 



can be accessed by device drivers (via the Accessible- 
Memory access methods). It is also possible for bus 
managers to set up DMA to a specified array of Physi- 
calMemory objects (see DMAMemory constructor 
methods). In fact, a bus manager can even set up DMA 
to a range of memory mapped into virtual memory, by 
first locking the virtual to physical mappings (see lockQ 
method of VirtualMemory), then calling the appropriate 
method of VirtualMemory (see getPhysicalMemory() 
method) to obtain an array of PhysicalMemory objects, 
and then passing this array to the appropriate DMAM- 
emory constructor. The reverse is also possible, where 
the DMAMemory object is first constructed, and then 
the underlying PhysicalMemory objects obtained in 
order to construct a VirtualMemory object (accessible 
via AccessibleMemory) which maps to the same Physi- 
calMemory objects. 

[01 87] Although PhysicalMemory is very useful in con- 
junction with VirtualMemory (which is AccessibleMem- 
ory) or in conjunction with DMAMemory, it is not usable 
by itself. This is true even on a system which has no 
MMU, where a CPU accesses physical memory directly. 
Even in that case, the PhysicalMemory object is not an 
object that is accessed, but when that PhysicalMemory 
object is mapped to virtual memory, the VirtualMemory 
object can be accessed, and its virtual addresses hap- 
pen to be the same as the underlying physical 
addresses. In this way, semantically. drivers or any other 
Java clients always access VirtualMemory objects, and 
never access PhysicalMemory objects. 
[01 88] The following constructors and public methods 
are defined: 

PhysicalMemory 

[0189] 

public PhysicalMemory (Address basePA, Address 
len) throws InvalidAddressException 

Parameters: 

baseFA - The base physical address of the physical 
memory to be allocated. 

len - The length in bytes of physical memory to be 
allocated. 



PhysicalMemory 
[0185] 

50 

Public class PhysicalMemory extends MainMemory 

[0186] The PhysicalMemory class allows bus manag- 
ers to obtain access to objects at specific physical 
addresses (such as device registers which are listed to ss 
be at a specific physical address in the Java system 
Database (JSD)) and then map them into virtual mem- 
ory (see VirtualMemory constructor methods) so they 



Throws: 

InvalidAddressException is thrown if the construc- 
tor called for the super-class (MainMemory) throws 
InvalidAddressException. 

private Physica!Memory(PhysicalMemory super- 
range, Address offset, Address len) throws Invali- 
dAddressException, AllocationException 
superRange - the super-range PhysicalMemory 
object. 

offset - The offset within the current PhysicalMem- 
ory object for the new sub-range, 
len - The length of the new sub-range. 
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Throws: 

invalidAddressException is thrown if either the off- 
set or the offset + newLength is beyond the range of 
the PhysicalMemory object from which the sub- 
range is being obtained, 5 

AllocationException is thrown if the superrange 
■ Memory object is no longer valid. 



[0190] The first constructor is public and can be used 
by a bus manager to allocate a PhysicalMemory object. 
This allocation does not actually involve anything done 
in the microkernel corresponding to the actual physical 
memory. Rather, the PhysicalMemory object is merely a 
descriptor for physical memory, and used for construc- 
tion of a VirtualMemory (actually an instantiate sub- 
class of VirtualMemory) or DMAMemory object. It is at 
the time that such a VirtualMemory or DMAMemory 
object is constructed that the microkernel verifies the 
PhysicalMemory object. 

[01 91 ] This first constructor does not take a Memory- 
Constraints object as a parameter. Basically the reason 
is as follows. There are two types of constraints speci- 
fied in a MemoryConstraints object, allocation con- 
straints and access constraints. Allocation constraints 
do not apply, since nothing is actually allocated, and 
since the caller specifies the base address. Access con- 
straints do not apply either, since PhysicalMemory 
objects are not accessible. 

[01 92] The second constructor is private, and is used 
internally by the getSubRange() method. It merely 
invokes the super-class (MainMemory) constructor for 
sub-ranges. 

toString 

[0193] 

public String toString() 
Returns: 

A string representing this PhysicalMemory object. 
getSubRange 
[0194] 

public PhysicalMemory getSub Rang e( Address off- 
set, Address newLength) throws InvalidAddressEx- 
ception 

Parameters: 

offset - The offset within the current PhysicalMem- 
ory object for the new sub-range. 
newLength - The length of the new sub-range. 

Returns: 

A PhysicalMemory object which is the specified 
sub-range. 
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Throws: 

InvalidAddressException is thrown if either the off- 
set or the offset + newLength is beyond the range of 
the PhysicalMemory object from which the sub- 
range is being obtained. 

AllocationException is thrown if the superrange 
Memory object is no longer valid. 

[0195] This method merely invokes the private con- 
structor of this PhysicalMemory object. 

getCacheMode 

[0196] 

public int getCacheMode() 
Returns: 

The cache mode, either MainMem- 
ory.CACHE_MODE_INHIBITED, MainMem- 
ory.CACHE_MODE_WRITE_THROUGH, or 
MainMemory.CACHE_MODE_COPY_BACK. 

[01 97] Note that this method allows a bus manager to 
determine how the physical memory is cached if the 
PhysicalMemory object has just been constructed, or if 
C ACH E_MO D E_D E FAU LT has been specified by set- 
CacheMode(). 
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[0193] 

public void setCacheMode(int mode) 

Parameters: 

mode - Set to one of: MainMem- 
ory.CACHE_MODE_DEFAULT, MainMem- 
ory.CACHEJ/IODEJNHIBlTED), 
MainMem- 

ory.CACHE_MODE_WRlTE_TH ROUGH, or Main- 
Memory. C ACH E_MODE_C OP Y_B AC K. 

[01 99] This method allows the bus manager, which 
should know about cache coherency of various compo- 
nents of the specific platform it supports, to control the 
caching of physical memory. For example, on platforms 
where a physical memory cache is not coherent with 
DMA accesses, it would be necessary for the bus man- 
ager to temporarily set the cache mode to CACHE- 
MODEJNIBIEED, while DMA transfers are set up. 
[0200] Specifically, this method requests the following, 
depending upon the specific value of mode: 

C AC H E_MOD E_D E FAU LT - Cache this range of 
physical memory according to what the default is for 
this type of physical memory on this platform. Note 
that, even on platforms that have physical address 
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caches, some physical memory (e.g. I/O registers) 
may need to be uncached to be used correctly, so 
such physical memory will be made uncached. 
Also, note that if this range of physical memory 
encompasses different types of physical memory 5 
that need to be treated differently, this mode will 
result in different sub-ranges being cached differ- 
ently, so that the entire range of physical memory is 
correctly cached. Whenever possible, this mode will 
result in caching being done to yield the greatest 70 
possible efficiency. 

CACHE_MODEJNHIBITED - If there is a cache, 
and if it can be uncached, it is uncached. If this is 
not possible, but is possible on a sub-range, it is 
done on any such subranges. Otherwise, nothing is 15 
done. 

CACHE_MODE_WRITE_TH ROUGH - If there is a 
cache, and if it can be converted to write-through 
mode, it is so converted. If this is not possible, but is 
possible on a sub-range, it is done on any such sub- 20 
ranges. Otherwise, nothing is done. 
,CACHE_MODE_COPY_BACK - If there is a 
cache, and if it can be converted to copy-back 
mode, it is so converted. If this is not possible, but is 
possible on a sub-range, it is done on any such sub- 25 
ranges. Otherwise, nothing is done. 

flushCache 

[0201] 30 

public void flushCache() 

[0202] Simply flushes the cache if the physical mem- 
ory is cached. If it is not cached, this method does noth- 35 
ing. Note that the physical caches are flushed for the 
entire range of addresses of this object. 
[0203] The PhysicalMemory class defines the follow- 
ing native methods corresponding to the abstract cache 
management methods defined in MainMemory. Each of 40 
these native methods is implemented by functionality in 
the microkernel. For more details, refer to the Microker- 
nel Interfaces Chapter. 

private native void setcachemode (long base, long 45 
len, int mode); 

private native int getcachemode(long base, long 
len); 

50 

private native void flushcache(long base, long len); 
VirtualAddressSpace 

[0204] 55 

public final class virtual AddressSpace extends 
AddressSpace 
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[0205] Each virtual machine has its ownVirtualAd- 
dressSpace. 

[0206] Besides the constructor, the following public 
string is defined: 

public final static String name = "virtual"; 

VirtualAddressSpace 

[0207] 

public VirtualAddressSpace (ExpansionBus b) 

[0208] This constructor first calls trie constructor of the 
super-class, AddressSpace. specifying the Expansion- 
Bus argument and the String defined above, so that 
they may be used by the puW»c methods. getExpansion- 
Bus() and getName() of AddressSpace Then, it calls 
the getAddressSize() and the aloe kJO native methods 
(see below) and supplies them to an protected initializa- 
tion routine of AddressSpace. so that they may then be 
used by the public methods. getLowestAddress() 
getHighestAddress(), and getlD() of AddressSpace. 
[0209] The VirtualAddressSpace defines the following 
native methods, implemented in the mcrokernel, which 
provide the size of addresses (m brts) and an ID for the 
address space, respectively The 10 rs used when con- 
structing VirtualMemory objects, so that the particular 
virtual address space for the mapping may be specified 
to the microkernel. 

private native int get Acta essSi2e{). 

private native int alloc-**,). 
VirtualMemory 
[0210] 

public abstract class V*tualMemory extends 
AccessibleMemory 

[021 1 ] The VirtualMemor y object t ep* esents memory 
that can be accessed directly via toad and store opera- 
tions from a CPU. so it taJlows mat VirtualMemory 
should be a sub-class of AccesstbieMenxxy. The Vir- 
tualMemory abstract class does net actually implement 
any of the access methods that are abstracted by the 
AccessibleMemory class, as those abstract methods 
are all finally implemented by sub-classes of Vir- 
tualMemory. The Virtual Menxyy ciass does provide 
facilities for managing the mappings of VirtualMemory 
objects to PhysicalMemory objects, and these facilities 
are common to all the sub-classes of VirtualMemory. 
[0212] VirtualMemory objects are always mapped to 
some physical memory (which ones it is mapped to can- 
not be determined unless the mappings are locked). 
However, even in the case when running on a machine 
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without an MMU, there are still VirtualMemory objects, 
and they are simply mapped one to-one such that a vir- 
tual address is always equal to the underlying physical 
address. 

[0213] The VirtualMemory class is abstract, since it 
extends AccessibleMemory without implementing any 
of the abstract methods defined in AccessibleMemory. 
VirtualMemory does not define any more abstract meth- 
ods though. 

[0214] When constructing a VirtualMemory object, 
note that sometimes it is not possible to map the entire 
amount of memory specified, so the getMemLengthQ 
method of Memory should be called to determine the 
actual amount of memory mapped. 
[021 5] The following constructors and public methods 
are defined: 



VirtualMemory 

[0216] As the VirtualMemory class is an abstract 
class, and thus cannot be instantiated, all three of the 
following protected constructors are used by sub- 
classes. Note that sometimes it is not possible to map 
the entire amount of memory specified, so the getMem- 
Length() method of Memory should be called to deter- 
mine the actual amount of memory mapped. 

protected VirtualMemory (int vasid, PhysicalMem- 
ory Q PMList, MemoryConstrairrts constraints) 
throws InvalidAddressException, AllocationExcep- 
tion 

Parameters: 

vasid - The virtual address space ID as obtained by 
calling the getlD() method of the AddressSpace 
class, which is the super-class of VirtualAd- 
dressSpace. 

PMList - An array of PhysicalMemory objects that 
are to be mapped into virtual memory m the order 
as they appear in the array, 
constraints - The allocation constraints are used 
now during the allocation and mapping of the virtual 
memory; the access constraints are stored in the 
Memory object and used later when it is accessed. 

Throws: 

InvalidAddressException is thrown if the microker- 
nel is not able to map virtual memory for the speci- 
fied parameters. 

AllocationException is thrown if the microkernel 
experiences an allocation failure when attempting 
to allocate virtual memory for the specified mapping 

[021 7] A request is made to the microkernel to do the 
mapping, providing the vasid. arrays of base physical 
addresses and lengths, allocation constraints, and an 
indication that the mapping must be locked. The micro- 
kernel returns the base virtual address and length 



mapped, which this constructor then uses to initialize 
this Memory object. 

protected virtualMemory(int vasid, Address len, 
5 MemoryConstraints constraints) throws InvalidAd- 
dressException, AllocationException 

; Parameters: 
vasid - The virtual address space ID as obtained by 
70 calling the getlD() method of the AddressSpace 
class, which is the super-class of VirtualAd- 
dressSpace. 

len - The length of virtual memory to be allocated, 
constraints - The allocation constraints are used 
15 now during the allocation and mapping of the virtual 
memory; the access constraints are stored in the 
Memory object and used later when it is accessed. 

Throws: 

20 InvalidAddressException is thrown if the microker- 
nel is not able to map virtual memory for the speci- 
fied parameters. 

AllocationException is thrown if the microkernel 
experiences an allocation failure when attempting 
25 to allocate virtual memory for the specified mapping 

[0218] In the case of-this second constructor, a 
request is made to the microkernel to do the mapping-, 
providing the length of memory, and allocation con- 
30 straints. The microkernel returns the base virtual 
address and length mapped, which this constructor 
then uses to initialize this Memory object. 

protected VirtualMemory (VirtualMemory super- 
35 Range, Address offset, Address len) throws Invali- 
dAddressException, AllocationException 

Parameters: 

superRange - the super-range VirtualMemory 
40 object. 

offset - The offset within the current VirtualMemory 

object for the new sub-range. 

len - The length of the new sub-range. 

45 Throws: 

InvalidAddressException is thrown if either the off- 
set or the offset + newLength is beyond the range of 
the VirtualMemory object from which the sub-range 
is being obtained. 

so AllocationException is thrown if the superrange 
Memory object is no longer valid. 

[021 9] This third protected constructor is used by sub- 
classes for their getSubRange() methods. This con- 
55 structor invokes the corresponding protected construc- 
tor of the super-class, AccessibleMemory. Also, a 
private variable is initialized to indicate that this sub- 
range VirtualMemory object is not locked. Note that 
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even if the super-range is locked, we do not initially indi- 
cate that the sub-range is locked. This is because we 
allow the microkernel to maintain a lock count on a par- 
ticular range of addresses. This means that when we 
lock this sub-range, the lock count for it would be what- 
ever count already accumulated for super-ranges plus 
one for this lock. 

[0220] Sub-ranges are kept on private linked lists of 
the super-range VirtualMemory object, so that the 
unMapO method works as described. 

unMap 

[0221] 

public void unMap() throws AllocationException 

Throws: 

AllocationException is thrown if the VirtualMemory 
object's linked list of sub-ranges is non-null, or if 
there is an internal failure of the unmapping done in 
the microkernel. 

[0222] If the validity of the super-class Memory is set 
to null (already unmapped), this call returns immedi- 
ately. This could happen if two threads were trying to 
call unMap at about the same time, and one got in 
ahead of the other. 

[0223] Provided the VirtualMemory object is not a 
sub-range, the microkernel is called to do the unmap, 
specifying a base virtual address and a length. If it is 
just a sub-range, it is merely removed from its super- 
range's Vector of sub-ranges. Finally, the validity of the 
super-class Memory is set to false. 

lock 

[0224] 

public long lock() throws AllocationException 

Returns: 

The number of bytes of this VirtualMemory object, if 
it was successfully locked; otherwise returns the 
number of bytes, starting at the beginning, that 
could have been locked, had it been a sub-range. 

Throws: 

AllocationException is thrown if the microkernel is 
not able to allocate physical memory to back the 
entire range of virtual memory, or H there is any 
other failure of the microkernel in getting this mem- 
ory mapped in. 

[0225] If already locked, this method returns immedi- 
ately. Otherwise, a request is made to the microkernel to 
get physical memory backing the entire range of virtual 
memory (if not already done), and to lock the mapping 
(or to increase the lock count in the case of a sub- 
range). The microkernel will need to keep track of multi- 
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pie requests in possibly multiple virtual address spaces 
that have locked either virtual memory mappings or 
DMA mappings to physical memory (including a lock 
count of mappings that are locked to each physical 
5 page). 

lockContiguous 
[0226] 

10 

public void lockContiguousQ throws AllocationEx- 
ception 

Returns: 

15 The number of bytes of this VirtualMemory object if 
it was successfully locked contiguously; otherwise if 
it would have been possible to lock a smaller sub- 
range (starting at the beginning of the object) the 
total number of bytes that could have been locked 

20 contiguously is returned. 

Throws: 

AllocationException is thrown if the VirtualMemory 
is already locked, but not contiguously, or if the 

25 microkernel is not able to allocate contiguous phys- 
ical memory to back the entire range of virtual 
memory, or if there is any other failure of the micro- 
kernel in getting this memory mapped in. It should 
be noted that the microkernel may abort the opera- 

30 tion and return a failure, resulting in this exception 
being thrown, if doing this contiguous locking would 
cause any locking of sub-ranges to be undone. 

[0227] If already locked contiguously, this method 

35 returns immediately. Otherwise, provided the Vir- 
tualMemory object is not already locked, a request is 
made to the microkernel to get contiguous physical 
memory backing the entire range of virtual memory and 
to lock the mapping. The microkernel will need to keep 

40 track of multiple requests in possibly multiple virtual 
address spaces that have locked either virtual memory 
mappings or DMA mappings to physical memory 
(including a lock count of mappings that are locked to 
each physical page). 

45 [0228] The reason for not allowing the contiguous 
locking to be done when the VirtualMemory object is 
already locked non-contiguously is that there was prob- 
ably a reason a client locked it non-contiguously, and it 
is thus better for the software that locked it non-contigu- 

so ously to do the unlock (and handle any side-effects of 
that temporary unlocking) rather than causing such 
side-effects to occur here. 

unlock 

55 

[0229] 

public void unlockQ throws AllocationException 
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Throws: 

AllocationException is thrown if there is some fail- 
ure in the microkernel to unlock the mapping. 

[0230] If the VirtualMemory object is already 
unlocked, this method returns immediately. Note that 
this causes the microkernel to decrement its lock count 
for this whole range; it does not affect any sub-ranges 
that may be locked. 

getPhysicalMemory 

[0231] 

public Physical Memory Q getPhysicalMemory () 
throws AllocationException 

Returns: 

An array of PhysicalMemory objects to which this 
VirtualMemory object is mapped (array order is for 
increasing virtual address), if this VirtualMemory 
object is locked (via either lockQ or lockContig- 
uonsQ); otherwise, if this VirtualMemory object is 
not locked, this method returns null. 

Throws: 

AllocationException is thrown if there is any failure 
of the microkernel in obtaining the information 
regarding the underlying physical memory (array of 
base addresses and lengths). 

[0232] If the VirtualMemory object is not locked, null is 
returned. Otherwise, if the PhysicalMemory objects 
have already been obtained for this VirtualMemory 
object (reference is kept in a private field of the Vir- 
tualMemory object), a reference to these pages is sim- 
ply returned. Otherwise, first a request is made to the 
microkernel to obtain arrays of base physical addresses 
and lengths. Then, using the information obtained from 
the microkernel, each PhysicalMemory object is con- 
structed. Before the array of PhysicalMemory objects is 
returned, reference to it is kept in a private field of this 
VirtualMemory object, so that further requests can be 
handled without involving the microkernel (as long as 
the VirtualMemory stays locked). 

getCacheMode 

[0233] 

public int getcacheMode() 

Returns: 

The cache mode. either MainMem- 
ory.CACHE_MODEJNHIBITED, MainMem- 
ory.CACHE_MODE_AMBIGUOUS, 
MainMem- 

ory.CACHE_MODE_WRITE_THROUGH, or Main- 



Memory.CACHE_MODE_COPY_BACK. 

[0234] Note that this method a'lows a bus manager to 
determine how the virtual memory is cached if the bus 
5 manager did not record how it had specified the virtual 
memory to be cached, or if CACHE_MODE_DEFAULT 
had been specified by setCacheMode(). and now the 
bus manager wants to know how exactly it was cached 
as default. 

70 

setCacheMode 
[0235] 

75 public void setcacheMode(int mode) 
Parameters: 

mode - Set to one of (see MainMemory): 
C AC H E_MOD E_D E FAU LT, 
20 C AC H E_MOD E_l N H I B ITE D, 

CACHE_MODE_WR(TE_TH ROUGH. or 
CACHE_MODE_COPY_BACK 

[0236] This method allows me bus manager, which 
25 should know about cache coherency of varousi compo- 
nents of the specific platform rt supports to control 
the caching of virtual memory For example, on plat- 
forms where a virtual memory cache rs not coherent 
with DMA accesses, it would be necessary tor the bus 
so manager to temporarily set the cache mode to 
CACHE_MODEJNHIBITED, while DMA transfers are 
set up (or to call flushCache() first and somehow guar- 
antee that the CPU(s) will not access the virtual mem- 
ory while DMA is done). 
35 [0237] Specifically, this method requests the following, 
depending upon the particular value of mode 

CACHE_MODE_DE FAULT ■ Cache this range of 
virtual memory according tc what the default is for 

4C this type of virtual memory, taking into account the 
caching requirements of re underling physical 
memory. Also, note that if th/s range of virtual mem- 
ory encompasses different sob-ranges that must be 
cached differently, this is handled, so that then 

45 entire range of virtual memory is correctly cached. 
Whenever possible, this mode will result m caching 
being done to yield the greatest poostte efficiency, 
CACHEJWODEJNHIBITED - If there is a cache, 
and if it can be uncached. r: rs uncached. If this is 

so not possible, but is possible on a sub-range, it is 
done on any such sub-ranges Otherwise, nothing 
is done. 

CACHE_MODE_WRITEJH ROUGH - H there is a 
cache, and if it can be converted to write-through 
55 mode, it is so converted. If this is not possible, but is 
possible on a sub-range, it is done on any such sub- 
ranges. Otherwise, nothing is done. 
.CACHE_MODE_COPY_BACK - If there is a 
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y 

cache, and if it can be converted to copy-back 
mode, it is so converted. If this is not possible, but is 
possible on a sub-range, it is done on any such sub- 
ranges. Otherwise, nothing is die. 

flushCache 
[0238] 



memory classes, with a MemoryDescriptor, by various 
bus managers. 

[0243] Besides the constructor, the following public 
string is defined: 

public final static String name ="dma"; 

DMAAddressSpace 



public void f lushCache() 

[0239] Simply flushes the cache if the virtual memory 
is cached. If it is not cached, this method does nothing. 
Note that the caches are flushed for the entire range of 
addresses of this object. 

[0240] The VirtualMemory class defines the following 
native methods. Each of these native methods is imple- 
mented by functionality in the microkernel. For more 
details, refer to the Microkernel Interfaces section. 

private native int physmap(longQ ret, int vasid, 
IongQ paddrs.longQ sizes, long minaddr, long max- 
addr, int align, int cacheMode, boolean locked, 
boolean waitformem); 

private native int map(longQ ret, int vasid, long size, 
long minaddr.long maxaddr, int align, int cacheM- 
ode, boolean locked.boolean waitformem); 

private native int unmap(int vasid, long base, long 
1 len, int howcreated); private native int dolock(long|] 
ret, int vasid, long base, long len); 

private native int dolockcontig(longQ ret, int vasid, 
long base, long len); private native int dounlock(int 
vasid, long base, long len); 
private native int getphys(intQ ret, int vasid, iongQ 
pBase, IongQ pLen, long base, long len); 

private native void setcachemode(int vasid, long 
base, long len, int mode); 

private native int getcachemode(int vasid, long 
base, long len); 

private native void flushcache(int vasid, long base, 
long len); 

DMAAddressSpace 
[0241] 

public final class DMAAddressSpace extends 
AddressSpace 

[0242] The DMAAddressSpace is not really used by 
the memory classes themselves, since it is assumed 
that a machine only has one DMA address space, but it 
is provided for completeness, and for use outside of the 



70 [0244] 

public DMAAddressSpace (ExpansionBus b) 

[0245] This constructor first calls the constructor of the 
is super-class, AddressSpace, specifying the Expansion- 
Bus argument and the String defined above, so that 
they may be used by the public methods, getExpansion- 
Bus() and getName() of AddressSpace. Then it calls the 
getAddressSizeO and the alloc_id() native methods 
20 (see below) and supplies them to an protected initializa- 
tion routine of AddressSpace, so that they may then be 
used by the public methods, get Lowest Add r ess () 
getHighestAddress() and getlD() of AddressSpace. 
[0246] The DMAAddressSpace defines the following 
25 native methods, implemented in the microkernel, which 
provide the size of addresses (in bits) and an ID for the 
address space, respectively. 

private native int getAddressSizeO; 

30 

private native int ailoc_id(); 
DMAMemory 
35 [0247] 

Public class DMAMemory extends Memory 

[0248] The DMAMemory object represents memory 

40 that can be accessed only via addressing external to the 
CPUs on some DMA channel. These DMA addresses 
are mapped via the DMA hardware to physical memory 
addresses. Thus, a DMAMemory object is always 
mapped to PhysicaiMemory objects. Since DMAMem- 

45 ory cannot be accessed either directly cr indirectly by 
the CPU(s). DMAMemory is neither a sub-class of 
AccessibleMemory nor MainMemory. Rather, DMAM- 
emory is a direct sub-class of Memory. 
[0249] When constructing a DMAMemory object, note 

so that sometimes it is not possible to map the entire 
amount of memory specified, so the getMemLength() 
method of Memory should be called to determine the 
actual amount of memory mapped. 
[0250] The following constructors and public methods 

55 are defined: 
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DMAMemory 
[0251] 

public DMAMemory (PhysicalMemory D PMList, 
MemoryConstraints constraints) throws InvalidAd- 
dressException, AllocationException, NotSupport- 
edException 

Parameters: 

PMList - An array of PhysicalMemory objects that 
are to be mapped into DMAmemory in the order as 
they appear in the array. 

constraints - The allocation constraints are used 
now during the allocation and'mapping of the virtual 
memory; the access constraints are ignored, since 
it is not possible for a CPU to access DMAMemory 

Throws: 

NotSupportedException is throw if a call to the 
microkernel indicates that DMA is not supported on 
this platform. 

InvalidAddressException is thrown if the construc- 
tor called for the super-class, Memory, throws Inval- 
idAddressException. if the specified length does 
not meet the allocation constraints, if the specified 
PhysicalMemory objects together cannot meet the 
allocation constraints, or if any of the PhysicalMem- 
ory objects is invalid. 

AllocationException is thrown if the specified Phys- 
icalMemory objects are not aligned so that they can 
be mapped to contiguous ranges of the DMAMem- 
ory object, or if there is any other internal error of 
the microkernel that prevents it from making the 
specified mapping. 

[0252] A request is made to the microkernel to allo- 
cate the DMA mappings, providing the arrays of base 
physical addresses and lengths, and the allocation con- 
straints. The microkernel returns the base DMA address 
and the length of DMA mapped, and then uses this 
information to initialize the Memory super-class. 

public DMAMemory (Address len, MemoryCon- 
straints constraints) throws InvalidAddressExcep- 
tion, AllocationException, NotSupportedException 

Parameters: 

len - The length of DMAMemory to be allocated, 
constraints - Only the allocation constraints are 
used; the access constraints are ignored 

Throws: 

NotSupportedException is throw if a call to the 
microkernel indicates that DMA is not supported on 
this platform. 

InvalidAddressException is thrown if the construc- 
tor called for the super-class. Memory, throws Inval- 
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idAddressExceptiou, or if the specified length does 
not meet the allocation constraints. 
AllocationException is thrown if there is any other 
internal error of the microkernel that prevents it 
5 from making the specified mapping. 

[0253] A request is made to the microkernel to allo- 
cate the DMA mappings, providing the length to allocate 
and the allocation constraints. The microkernel returns 
w the base DMA address and the length of DMA mapped, 
and then uses this information to initialize the Memory 
super-class. 

private DMAMemory(DMAMemory superRange, 
75 Address offset, Address len) throws InvalidAd- 
dressException, AllocationException 

Parameters: 

superRange - the super-range DMA object, offset - 
20 The offset within the current DMA object for the new 
sub-range. 

len - The length of the new sub-range. 

Throws: 

25 InvalidAddressException is thrown if either the off- 
set or the offset + newLength is beyond the range of 
the DMAMemory object from which the sub-range 
is being obtained, or if the wad sub-range does not 
meet the allocation constraints of the original 

30 DMAMemory object. 

AllocationException is thrown if the superrange 
Memory object is no longer valid. 

[0254] This private constructor is used by the getSub- 
35 Range() method. This constructor invokes the corre- 
sponding protected constructor of the super-class, 
Memory 

toString 

40 

[0255] 

public String toString() 

45 Returns: 

A string representing this DMAMemory object. 

unMap 

so [0256] 

public void unMap() throws AllocationException 
Throws: 

55 AllocationException is thrown if the DMAMemory 
object's linked list of sub-ranges is non-null, or if 
there is an internal failure of the unmapping done in 
the microkernel. 
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[0257] If the validity of the super-class Memory is set 
to null (already unmapped), this call returns immedi- 
ately. This could happen if two threads were trying to 
call the unMap() method at about the same time, and 
one got in ahead of the other. Provided the DMAMem- 
ory object is not a sub-range, the microkernel is called 
to do the DMA deallocation, specifying a base DMA 
.address and a length. If it is just a sub-range, it is merely 
removed from its superrange's Vector of sub-range. 
Finally, the validity of the super-class Memory is set to 
false. 

getPhyslcalMernory 
[0258] 



public PhysicalMemoryQ 
throws AllocationException 



getPhysica!Memory() 



70 



range. 



15 



Throws: 

InvalidAddressException is thrown if either the off- 
set or the offset + newLength is beyond the range of 
the VirtualMemory object from which the sub-range 
is being obtained. 

AllocationException is thrown if the superrange 
Memory object is no longer valid. 

[0261] This method merely calls the private DMAM- 
emory constructor that is used to construct sub-ranges. 

toString 

[0262] 

public String toStringQ 



Returns: 

An array of PhysicalMemory objects to which this 
DMAMemory is mapped (array order is for increas- 
ing DMA address). 

Throws: 

AllocationException is thrown if there is any failure 
of the microkernel in obtaining the information 
regarding the underlying physical memory (array of 
base addresses and lengths). 

[0259] If the PhysicalMemory objects have already 
been obtained for this DMAMemory object (reference is 
kept in a private field of the DMAMemory object), a ref- 
erence to these pages is simply returned. Otherwise, 
first a request is made to the microkernel to obtain 
arrays of base physical addresses and lengths. Then, 
using the information obtained from the microkernel, 
each PhysicalMemory object is constructed. Before the 
array of PhysicalMemory objects is returned, reference 
to it is kept in a private field of this DMAMemory object, 
so that further requests can be handled without involv- 
ing the microkernel. 



20 Returns: 

A string representing this DMAMemory object. 

[0263] The DMAMemory class defines the following 
native methods. Each of these native methods is imple- 
25 merited by functionality in the microkernel, i 

private native boolean supportedO; 

private native int physmap(longQ ret, longQ paddrs, 
30 longQ sizesjong minaddr, long maxaddr, int align, 
boolean waitformem); 

private native int map(long[] ret, long size, long 
minaddr.long maxaddr, int align, boolean wait- 
35 formem); 

private native int unmap(long base, long len); 

private native int getphys(intfl ret, longQ pBase, 
40 longQ pLen,long base, long len); 

VirtuallOMemory 



20 



getSubRange [0264] 

45 

[0260] public abstract class VirtuallOMemory extends Vir- 

tualMemory 

public Memory getSubRange(Address offset, 

Address newLength) throws InvalidAddressExcep- [0265] The following constructors and public methods 

tion so are defined: 



Parameters: 

offset - The offset within the current DMAMemory 

object for the new sub-range. 

newLength - The length of the new sub-range. ss 

Returns: 

A DMAMemory object which is the specified sub- 



VirtuallOMemory 
[0266] 

protected VirtuallOMemory (int vasid, Physi- 
calMemory[ ] PMList, Memoryconstraints con- 
straints) throws InvalidAddressException, 
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AHocationException ^ getSubRange 



protected VirtuallOMemory(int vasid, Address len, 
MemoryConstraints constraints) throws InvalidAd- 
dressException, AHocationException 

protected - VirtuallOMemory (VirtuallOMemory 
; superrange, Address offset, Address len) throws 
InvalidAddressException, AHocationException 

[0267] Each of these three protected constructors is 
only used by sub-classes, and merely invoke the corre- 
sponding constructor of VirtualMemory. Refer to Vir- 
tualMemory for more details. 

[0268] The VirtuallOMemory abstract class currently 
provides no additional functionality but is merely defined 
in case there are ever common methods between 
Swapped Virtual IOM emory and UnSwapped Virtual I- 
OMemory. Currently, this class only defines three pro- 
tected constructors which merely invoke the 
corresponding constructors of the super-class Vir- 
tualMemory. 

SwappedVirtuallOMemory 
[0269] 

public class SwappedVirtuallOMemory extends Vir- 
tuallOMemory 

[0270] The following constructors and public methods 
are defined: 

SwappedVirtuallOMemory 
[0271] 

public SwappedVirtuallOMemory (int vasid, Physi- 
calMemory[ ] PMList, MemoryConstraints con- 
straints) throws InvalidAddressException, 
AHocationException, NotSupportedException 
public SwappedVirtuallOMemory (int vasid, 
Address len, MemoryConstraints constraints) 
throws InvalidAddressException, AHocationExcep- 
tion, NotSupportedException 
private SwappedVirtuallOMemory (SwappedVirtua- 
llOMemory superrange, Address offset, Address 
len) throws InvalidAddressException, AHocationEx- 
ception 

[0272] As long as SwappedVirtuallOMemory is sup- 
ported on this platform, each of these three constructors 
merely invoke the corresponding constructor of Virtuall- 
OMemory, which in turn invokes the corresponding con- 
structor of VirtualMemory. Refer to VirtualMemory for 
more details, rf SwappedVirtuallOMemory is not sup- 
ported on this platform, NotSupportedException is 
thrown. 



[0273] 

5 public SwappedVirtuallOMemory getsub- 
Range( Address offset, Address newLength) throws 
InvalidAddressException, AHocationException 

Parameters: 

w offset - The offset within the current SwappedVirtu- 
allOMemory object for the new sub-range. 
newLength - The length of the new sub-range. 

Returns: 

is A SwappedVirtuallOMemory object which is the 
specified sub-range. 

Throws: 

InvalidAddressException is thrown if either the off- 
20 set or the offset + newlength is beyond the range of 
the SwappedVirtuallOMemory object from which 
the sub-range is being obtained, or if the Woposed 
sub-range does not meet the allocation constraints 
of the original SwappedVirtuallOMemory object. 
25 AHocationException is thrown if the superrange 
Memory object is no longer valid. 

[0274] This method merely invokes the third construc- 
tor method of SwappedVirtuallOMemory, which eventu- 
30 ally invokes the third constructor method of 
VirtualMemory to construct the sub-range. 

toString 

35 [0275] 

public String toString() 
Returns: 

A string representing this Swapped Virtual lOMem- 
40 ory object. 

[0276] The SwappedVirtuallOMemory class defines- 
the following native methods corresponding to the 
abstract access methods that are defined in Accessible- 

45 Memory. Each of these native methods is implemented 
by functionality in the microkernel, which must handle 
both the fact that the memory is byteswapped, and that 
it is I/O memory which may, depending upon the plat- 
form, require additional operations to deal with the fact 

so that I/O memory may not be coherent with other system 
memory. 

protected native boolean supported(); 
55 protected native int ncksum(long adr, long len); 
protected native void nSetByte(long adr, byte x); 
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protected native void nSetShort(long adr, short x); 
protected native void nSettnt(long adr, int x); 
protected native void nSetLong(long adr, long x); 



protected native void nSetBytes(long adr, 
bytes(], int bytesOffset, int length); 



byte 



[0279] As long as UnSwapped Virtual lOMemory is 
supported on this platform, each of these three con- 
structors merely invoke the corresponding construc- 
tor of Virtual lOMemory, which in turn invokes the 
corresponding constructor of VirtualMemory. Refer to 
VirtualMemory for more details. If UnSwappedVirtuall- 
OMemory is not supported on this platform, NotSup- 
portedException is thrown. 



protected native void nSetlntArray(long adr, byte 
bytesQ, int bytesoffset, int length_int); 

protected native byte nGetByte(long adr); 

protected native short nGetshort(long adr); 

protected native int nGetlnt(long adr); 

protected native long nGetLong(long adr); 

protected native void nGetBytes(long adr, byte 
bytesQ, int bytesoffset, int length); 

protected native void nGetintArray(long adr, byte 
bytesQ, int bytesOffset, int length_int); 

protected native void nRegisterSource(long adrl, 
long len); 

protected native void nCopy(long adr2, long len, int 
copy ID); 

UnSwappedVirtuallOMemory 

[0277] 

public class UnswappedVirtualloOMemory extends 
Virtual lOMemory 

UnswappedVirtuallOMemory 

[0278] 



10 getSubRange 
[0280] 

public UnswappedVirtuallOMemory getSub- 
is Range(Address offset, Address newLength) throws 
InvalidAddressException, AllocationException 

Parameters: 

offset - The offset within the current UnswappedVir- 
20 tual lOMemory object for the new sub-range. 

newLength • The length of the new sub-range. 

Returns: 

A UnSwappedVirtuallOMemory object which is the 
25 specified sub-range. 

Throws: 

InvalidAddressException is thrown if either the off- 
set or the offset + newLength is beyond the range of 

30 the UnSwappod Virtual lOMemory object from which 
the sub-range is being obtained, or if the proposed 
sub-range does not meet the allocation constraints 
of the original UnSwappedVirtuallOMemory object. 
AllocationException is thrown if the superrange 

35 Memory object is no longer valid. 

[0281 ] This method merely invokes the third construc- 
tor method of UnSwappedVirtuallOMemory which 
eventually invokes the third constructor method of Vir- 
40 tualMemory to construct the strange. 

toString 



[0282] 

45 

public String toStringQ 



public UnswappedVirtuallOMemory (int vasid, 
PhysicalMemory Q PMList, Memoryconstraints 
constraints) throws InvalidAddressException, Allo- 
cationException, NotSupportedException 

public UnswappedVirtuallOMemory (int vasid, 
Address len.MemoryConstraints constraints) 
throws InvalidAddressException, AllocationExcep- 
tion , NotSupported Exception 

private UnswappedVirtuallOMemory (Unswapped- 
VirtuallOMemory superrange. Address offset. 
Address len) throws InvalidAddressException, Allo- 
cationException 



Returns: 

A string representing this UnswappedVirtuall- 
so OMemory object. 



[0283] The UnSwappedVirtuallOMemory class 
defines the following native methods corresponding to 
the abstract access methods that are defined in Acces- 
55 sibleMemory Each of these native methods is imple- 
mented by functionality in the microkernel, which must 
handle the fact that it is I/O memory which may, depend- 
ing upon the platform, require additional operations to 
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deal with the fact that I/O memory may not be coherent 
with other system memory. Unlike the corresponding 
native methods of UnSwappedVirtuailOMemory the 
native methods here do not have to deal with byte- 
swapping. 
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[0286] 



protected native boolean supported(); 

protected native int ncksum(long adr, long len); 

protected native void nSetByte(long adr, byte x); 

protected native void nSetShort(iong adr, short x); 

protected native void nSetlnt(iong adr, int x); 

protected native void nSett_ong(long adr, long x); 

protected native void nSetBytes(long adr, byte 
bytesQ, int bytesOffset, int length); 

protected native void nSetlntArray(long adr, byte 
bytesQ, int bytesOffset, int lengthjnt); 

protected native byte nGetByte (long adr); 

protected native short nGetshort(long adr); 

protected native int nGetlnt(long adr); 

protected native long nGetLong(long adr); 

protected native void nGetBytes(long adr, byte 
bytesQ, int bytesOffset, int length); 

protected native void nGetlntArray(long adr, byte 
bytesQ, int bytesoffset, int lengthjnt); 

protected native void nRegisterSource(long adrl, 
long len); 

protected native void nCopy(long adr2, long len, int 
copylD); 

VirtualRegularMemory 

[0284] 

public abstract class VirtualRegularMemory 
extends VirtualMemory 

[0285] The following constructors and public 
methods are defined: 



5 protected VirtualRegularMemory (int vasid, Physi- 
calMemory Q PMList, MemoryConstraints con- 
straints) throws . InvalidAddressException, 
AllocationException 

10 protected VirtualRegularMemory(int vasid, Address 
len, MemoryConstraints constraints) throws Invali- 
dAddressException, AllocationException 

protected Virtual RegularMemory (VirtualRegu- 
is larMemory superrange, Address offset, Address 
len) throws InvalidAddressException, AllocationEx- 
ception 

[0287] Each of these three protected constructors is 
20 only used by sub-classes, and merely invoke the corre- 
sponding constructor of VirtualMemory. Refer to Vir- 
tualMemory for more details. 

[0288] The VirtualRegularMemory abstract class cur- 
rently provides no additional functionality, but is merely 

25 defined in case there are ever common methods 
between SwappedVirtual RegularMemory and 
Unswapped Virtual RegularMemory Currently, this class 
only defines three protected constructors which merely 
invoke the corresponding constructors of the super- 

30 class VirtualMemory. 

swappedvirtualRegularMemory 
[0289] 

35 

public class SwappedvirtualRegularMemory 
extends VirtualRegularMemory 

[0290] The following constructors and public methods 
40 are defined: 



SwappedvirtualRegularMemory 
[0291] 

public Swapped Virtual RegularMemory (int vasid, 
PhysicalMemory Q PMList, MemoryConstraint con- 
straints) throws InvalidAddressException, Alloca- 
tionException, Notsupported Exception 

public SwappedvirtualRegularMemory (int vasid, 
Address len, MemoryConstraints constraints) 
throws InvalidAddressException, AllocationExcep- 
tion, NotSupportedException 

private SwappedvirtualRegularMemory (Swapped- 
virtualRegularMemory superrange, Address offset, 
Address len) throws InvalidAddressException, Allo- 
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cationException 



[0292] As long as SwappedVistualReguIarMemory is 
supported on this platform, each of these three con- 
structors merely invoke the corresponding constructor s 
of Virtual Regular Memory, which in turn invokes the 
corresponding constructor of VirtualMemory. Refer to 
•VirtualMemory for more details. If SwappedVirtualReg- 
ularMemory is not supported on this platform, NotSup- 
ported Exception is thrown. 



10 



getSubRange 
[0293] 

public SwappedVirtualRegularMemory getSub- 
Range (Address offset, Address newLength) 
throws InvalidAddressException, AllocationExcep- 
tion 

Parameters: : 

offset - The offset within the current SwappedVirtu- 
alRegularMemory object for the new sub-range. 
newLength - The length of the new sub-range. 

Returns: 

A SwappedVirtualRegularMemory object which is 
the specified sub-range. 



15 



20 



25 



30 



Throws: 

InvalidAddressException is thrown if either the off- 
set or the offset + new Length is beyond the 
range of the SwappedVirtualRegularMemory object 
from which the sub-range is being obtained, or if the 
proposed sub-range does not meet the allocation 35 
constraints of the original SwappedVirtualRegu- 
larMemory object. 

AllocationException is thrown if the superrange 
Memory object is no longer valid. 

40 

[0294] This method merely invokes the third construc- 
tor method of SwappedVirtualRegularMemory, which 
eventually invokes the third constructor method of Vir- 
tualMemory to construct the sub-range. 



sibleMemory. Each of these native methods is imple- 
mented by functionality in the microkernel, which must 
handle both the fact that the memory is byte-swapped. 

protected native boolean supportedO; 

protected native int ncksum(long adr, long len); 

protected native void nSetByte(long adr, byte x); 

protected native void nSetShort(long adr, short x); 

protected native void nSetlnt(long adr, int x); 

protected native void nSetLong(long adr, long x); 

protected native void nSetBytes(long adr, byte 
bytes 0. int bytesOffset, int length); 

protected native void nSetlntArray(long adr, byte 
bytesQ, int bytesOffset, int lengthjnt); 

protected native byte nGetByte(Long adr); 

protected native short nGetshort(long adr); 

protected native int nGetlnt(long adr); 

protected native long nGetLong(long adr); 

protected native void nGetBytes(iong adr, byte 
bytesQ. int bytesOffset, int length); 

protected native void nGetlntArray(long adr, byte 
bytesQ, int bytesOffset, int lengthjnt); 

protected native void nRegisterSource(long adrl, 
long len); 

protected native void nCopy(long adr2, long len, int 
copylD); 



toString 
[0295] 

public String toString() 
Returns: 

A string representing this SwappedVirtualRegu- 
larMemory object. 

[0296] The SwappedVirtualRegularMemory class 
defines the following native methods corresponding to 
the abstract access methods that are defined in Acces- 



UnSwappedVirtualRegularMemory 
45 [0297] 

public class UnSwappedVirtualRegularMemory 
extends VirtualRegularMemory 

so [0298] The following constructors and public methods 
are defined: 

UnSwappedVirtualRegularMemory 
55 [0299] 

public UnSwappedVirtualRegularMemory (int 
vasid, PhysicalMemory Q PMList, MemoryCon- 
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straints constraints) throws InvalidAddressExcep- 
tion, AllocationException, NotSupportecl Exception 

public UnSwapped Virtual RegularMemory (int 
vasid, Address len.MemoryConstraints constraints) 
throws InvalidAddressException, AllocationExcep- 
tion, NotSupportedException 

private UnSwappedVirtual RegularMemory 

(UnSwappedVirtualRegularMemory superrange, 
Address offset, Address len) throws InvalidAd- 
dressException, AllocationException 

[0300] As long as UnSwappedVirtualRegularMemory 
is supported on this platform, each of these three con- 
structors merely invoke the corresponding constructor 
of Virtual RegularMemory, which in turn invokes the cor- 
responding constructor of VirtualMemory. Refer to 
VirtualMemory for more details. If UnSwappedVirtual- 
RegularMemory is not supported on this platform, Not- 
SupportedException is thrown. 

getSubRange 

[0301] 

public UnSwappedVirtualRegularMemory getSub- 
Range (Address offset, Address newLength) 
throws InvalidAddressException, AllocationExcep- 
tion 

Parameters: 

offset - The offset within the current UnSwapped- 
VirtualRegularMemory object for the new sub- 
range. 

newLength - The length of the new sub-range. 



toString 
[0303] 

5 public String toString() 
Returns: 

A string representing this UnSwappedVirtualRegu- 
larMemory object. 

70 

[0304] The UnSwappedVirtualRegularMemory class 
defines the following native methods corresponding to 
the abstract access methods that are defined in Acces- 
sibieMemory. Unlike the corresponding native methods 
is of SwappedVirtual RegularMemory, the native methods 
here do not have to deal with byte-swapping. 

protected native boolean supported(); 

20 protected native int ncksum(long adr, long len); 

protected native void nSetByte(long adr, byte x); 

protected native void nSetShort(long adr, short x); 

25 \ 

protected native void nSetlnt(long adr, int x); 

protected native void nSetLong(long adr, long x); 

30 protected native void nSetBytes(long adr, byte 
bytesQ, int bytesOffset, int length); 

protected native void nSet!ntArray(long adr, byte 
bytesQ, int bytesOffset, int lengthjnt); 
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protected native byte nGetByte(long adr); 



Returns: 

A UnSwappedVirtualRegularMemory object which 
is the specified sub-range. *o 

Throws: 

InvalidAddressException is thrown if either the off- 
set or the offset + newLength is beyond the range of 
the UnSwappedVirtualRegularMemory object from 
which the sub-range is being obtained, or if the pro- 
posed sub-range does not meet the allocation 
constraints of the original UnSwappedVirtualRegu- 
larMemory object. 

AllocationException is thrown if the superrange 
Memory object is no longer valid. 

[0302] This method merely invokes the third construc- 
tor method of UnSwappedVirtualRegularMemory, which 
eventually invokes the third constructor method of Vir- ss 
tualMemory to construct the sub-range. 



protected native short nGetShort(long adr); 
protected native int nGetlnt(long adr); 
protected native long nGetLong(long adr); 



protected native void nCopy(long adr2, long len, int 
copy ID); 



protected native void nGetBytes(long adr, byte 
45 bytesQ, int bytesOffset, int length); 

protected native void nGetintArray(long adr, byte 
bytes(), int bytesOffset, int lengthjnt); 

so protected native void nRegisterSource(long adrl, 
long len); 
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[0305] 
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public final class PortlOAddressSpace extends 
AddressSpace 

[0306] The PortlOAddressSpace is not really used by 
the memory classes themselves, since it is assumed 
that a machine only has one port I/O address space, but 
it is provided tor completeness, and for use outside of 
the memory classes, with a MemoryDescriptor, by vari- 
ous bus managers. 

[0307] Besides the constructor, the following public 
string is defined: 

public final static String name="portio"; 

PortlOAddressSpace 

[0308] 

public PortlOAddressSpace (ExpansionBus b) 

[0309] This constructor first calls the constructor of the 
super-class. AddressSpace, specifying the Expansion- 
Bus argument and the String defined above, so that 
they may be used by the public methods, getExpansion- 
Bus(), and getName() of AddressSpace. Then it calls 
the getAddressSize() and the alloc Jd() native methods 
(see below) and supplies them to an protected initializa- 
tion routine of AddressSpace, so that they may then be 
used by the public methods, getl_owestAddress(), 
getHighestAddress(), and getlDQ of AddressSpace. 
[031 0] The PortlOAddressSpace defines the following 
native methods, implemented in the microkernel, which 
provide the size of addresses (in bits) and an ID for the 
address space, respectively. 

private native int getAddressSize(); 

private native int alloc_id(); 
PortlOMemory 
[0311] 

public abstract class PortlOMemory extends 
AccessibleMemory 
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[0312] The PortlOMemory abstract class provides 
some minor functionality that is common between 
SwappedPortlOMemory and UnSwappedPortlOMem- 
ory. 

[031 3] The following constructors and public methods 55 
are defined: 



[0314] 

protected PortlOMemory (Address p, Address len, 
MemoryConstraints constraints) 

Parameters: 



10 [0315] 



f> Base Address 
len-length 

constraints - Memory Constraints 

[0316] This constructor merely calls the protected 
constructor of the super-class, AccessibleMemory. 

setCacheMode 

[0317] 

public void setCacheMode(int mode) 
Parameters: 
[0318] 

mode - Requested cache mode. 

[0319] This method does nothing; regardless what 
cache mode is specified, no caching is supported for 
PortlOMemory, so the mode is always kept as 
CACHE_MODE_INHIBITED. 

getCacheMode 



40 [0320] 



public int getCacheModeO 

Returns: 
Cache mode. 



[0321] This method always returns 

CACHE_MODE_INHIBITED. 

so flushCache 

[0322] 

public void f lushCacheQ 



[0323] Since there is no cache to flush, this method 
does nothing. 
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[0324] 

public class SwappedPortlOMemory extends Portl- 
OMemory 

[0325] The following constructors and public methods 
are defined: 

SwappedPortlOMemory 
[0326] 

public SwappedPortlOMemory( Address p, Address 
len, MemoryConstraints constraints) 

Parameters: 

p-BaseAddress 

len-length 

constraints - Memory Constraints 

[0327] This constructor merely calls the protected 
constructor of the super-class. PortlOMemory 

getSubRange 

[0328] 

protected getSubRange(Address offset. Address 
newLength) throws InvalidAddressException, Allo- 
cationException 



[0330] 

5 public String toString() 
Returns: 

A string representing this SwappedPortlOMemory 
object. 

10 

[0331 ] The SwappedPortlOMemory class defines the 
following native methods corresponding to the abstract 
access methods that are defined in AccessibleMemory. 
Each of these native methods is implemented by func- 
15 tionality in the microkernel, which must handle both the 
fact that the memory is byte-swapped, and that it is port 
memory. 

protected native boolean supportedO; 

20 

protected native int ncksum(long adr, long len); 
protected native void nSetByte(long adr, byte x); 
25 protected native void nSetShort(long adr, short x); 
protected native void nSetlnt(long adr, int x); 
protected native void nSetLong(long adr, long x); 

30 

protected native void nSetBytes(long adr, byte 
bytesQ, int bytesOffset, int length); 



Parameters: 

offset - The offset within the current SwappedPortl- 35 
OMemory object for the new sub-range. 
newLength - The length of the new sub-range. 

Returns: 

A Memory object (actually specifically a Swapped- 
PortlOMemory object) which is the specified sub- 
range. 

Throws: 

InvalidAddressException is thrown if either the off- 
set or the offset + newLength is beyond the range of 
the 

SwappedPortlOMemory object from which the sub- 
range is being obtained, or if the proposed sub- 
range does not meet the constraints (e.g. align- 
ment) of the original SwappedPortlOMemory 
object. 

AllocationException is thrown if the superrange 
Memory object is no longer valid. 

[0329] This method merely invokes the constructor 
method of SwappedPortlOMemory. 



protected native void nSetlntArray(long adr, byte 
bytesQ, int bytesOffset, int lengtjnt); 

protected native byte nGetByteflong adr); 



protected native short nGetShort(long adr); 

40 

protected native int nGetlnt(long adr); 

protected native long nGetLong(long adr); 

45 protected native void nGetBytes(long adr, byte 
bytesQ, int bytesOffset, int length); 

protected native void nGetlntArray(long adr, byte 
bytesQ, int bytesOffset, int length_int); 

50 

protected native void nRegisterSource(long adrl, 
long len); 

protected native void nCopy(long adr2, long len, int 
55 copylD); 
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[0332] 

public class UnswappedPortlOMemory extends 
PortlOMemory 

[0333] The following constructors and public methods 
are defined: 

Uns wa pped Po rtl OMemory 
[0334] 

public UnSwappedPortlOMemory(Address p, 
Address len, MemoryConstraints constraints) 

Parameters: 
p-BaseAddress 
len-Length . 

constraints - Memory Constraints 

[0335] This constructor merely calls the protected 
constructor of the super-class, PortlOMemory. 

getSubRange 

[0336] 

protected getSubRange(Address offset, Address 
newLength) throws InvalidAddressException 

Parameters: 

offset - The offset within the current UnSwapped- 
PortlOMemory object for the new sub-range. 
newLength - The length of the new sub-range. 

Returns: 

A Memory object (actually specifically a 
UnSwappedPortlOMemory object) which is the 
specified sub-range. 

Throws: 

InvalidAddressException is thrown if either the off- 
set or the offset + newLength is beyond the range of 
the UnSwappedPortlOMemory object from which 
the sub-range is being obtained, or if the proposed 
sub-range does not meet the constraints (e.g. align- 
ment) of the original UnSwappedPortlOMemory 
object. 

AllocationException is thrown if the superrange 
Memory object is no longer valid. 

[0337] This method merely invokes the constructor 
method of UnswappedPortlOMemory. 



[0338] 

5 public String toStringO 
Returns: 

A string representing this UnSwappedPortlOMem- 
ory object. 

10 

[0339] The UnswappedPortlOMemory class defines 
the following native methods corresponding to the 
abstract access methods that are defined in Accessible- 
Memory. Each of these native methods is implemented 
15 by functionality in the microkernel, which must handle 
both the fact that the memory is port memory. 

protected native boolean supportedO; 

20 protected native int ncksum(long adr, long len); 

protected native void nSetByte(long adr, byte x); 

protected native void nSetShort(long adr, short x); 

25 } 

protected native void nSettnt(long adr, int x); 

protected native void nSetLong(long adr, long x); 

30 protected native void nSetBytes(long adr, byte 
bytesQ, int bytesOffset, int length); 

protected native void nSetlntArray(long adr, byte 
bytesQ, int bytesOffset, int lengthjnt); 

35 

protected native byte nGetByte(long adr); 

protected native short nGetShort(long adr); 

40 protected native int nGetlnt(long adr); 

protected native long nGetLong(long adr); 

protected native void nGetBytes(long adr, byte 
45 bytesO, int bytesOffset, int length); 

protected native void nGetlntArray(iong adr, byte 
bytesQ, int bytesOffset, int lengthjnt); 

so protected native void nRegisterSource(long adrl, 
long len); 

protected native void nCopy(long adr2, long len, int 
copy ID); 

55 

Microkernel Memory and DMA Methods 



[0340] DMA and Memory methods 80 and 82 of 
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microkernel 62 consist entirely of the set of native meth- 
ods of the various Java classes. Together, these native 
methods are contained in a library of functions for a par- 
ticular microkernel, and each function of that library 
either handles the native method itself, or performs a 5 
system call to the microkernel to handle the native 
method. 



[0343] 

private native int alloc_id(); 

[0344] Since it is assumed that there is only one phys- 
ical address space, the microkernel simply returns 0. 

PhysicalMemory 



setcachemode 



[0347] 
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PhysicalAddressSpace 

[0341] The PhysicalAddressSpace class defines the 
following native methods: 



getAddressSize 
[0342] 

private native int getAddressSize(); 
Returns the number of bits of physical addresses 20 
alloc id 



25 



30 



[0345] The PhysicalMemory class defines the follow- 
ing native methods corresponding to the abstract cache 
management methods defined in MainMemory. 35 
[0346] The following native methods control caching 
of data associated with physical addresses on the par- 
ticular platform. 



40 



private native void setcachemode(long base, long 
len, int mode); 45 

[0348] This native method sets the caching for physi- 
cal memory, starting at the physical address, base, and 
continuing for a length in bytes of len. The caching is set 
based upon the following possible values of mode (for 50 
any other values of mode, do nothing): 

• CACHE_MODE_DEFAULT - Cache this range of 
physical memory according to what the default is for 
this type of physical memory on this platform. Note 55 
that, even on platforms that have physical address 
caches, some physical memory (e.g. I/O registers) 
may need to be uncached, and it is expected that 



the microkernel will make them uncached if they 
need to be uncached to be used correctly. Also, 
note that, if the range specified encompasses dif- 
ferent types of physical memory that need to be 
treated differently, the microkernel is expected to 
cache different sub-ranges differently, if necessary, 
so that the entire range is cached correctly. Other 
than these restrictions, the microkernel should try 
to set up caching to effect the greatest efficiency 
that is correct. In other words, rf caches can be 
used, while still maintaining data integrity, they 
should. 

• CACHE_MODEJNHIBITED - If it is possible to 
cache this physical memory and if it is possible to 
disable its caching, then disable its caching. Other- 
wise, do nothing. If this in not possible over the 
entire range, but is possiWe over one or more sub- 
ranges, do it at least over any such sub-ranges. 

• CACHE_MODE_WRlTE_TH ROUGH - H it is possi- 
ble to cache this physical memory, and if rt is possi- 
ble to set the caching to wrrte throu^i mode, then 
set it as such. Otherwise, do nothing H this is not 
possible over the entire range, but is possible over 
one or more sub-ranges, do rt at least ewer any such 
sub-ranges. -; 

• CACHE_MODE_COPY_BACK * If it is possible to 
cache this physical memory and rf rt is possible to 
set the caching to copy-back mode, then set it as 
such. Otherwise, do nothing M this m not possible 
over the entire range, but is possjbe over one or 
more sub-ranges, do rt at leasJ over those sub- 
ranges. 

getcachemode 

[0349] 

private native int getcacnemode<iong base, long 
len); 

[0350] This native method gets the caching tor physi- 
cal memory, starting at the physcai address, base, and 
continuing for a length in bytes o< ten Of* of the follow- 
ing values is to be returned 

• CACHE_MODE_AMBIGUOU5 • W the entire range 
is not cached the same way. or if none of the follow- 
ing return values apply. 

• CACHE_MODE_INHIBITED • « there is no cache, 
or rf there is a cache, but this physical memory 
range is now uncached. 

• C AC HE_MOD E_WR1TE_TH ROUGH . If this range 
of physical memory is now cached in write-through 
mode. 

• CACHE_MODE_COPY_BACK - H this range of 
physical memory is now cached in copy-back 
mode. 
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flushcache 
[0351] 

private native void flushcache(Iong base, long len); 

[0352] If any sub-range of this range of physical mem- 
ory is cached in CACHE_MODE_COPY_BACK mode, 
flush any such caches if possible. If it is not pos- 
sible to flush them, convert them to 
CACHEJVIODEJNHIBITED. If even this is not possible, 
it is assumed that somehow the platform was designed 
so that DMA is always coherent with respect to any 
physical caches, and in those cases, it is fine for this 
method to do nothing. 

VirtualAddressSpace 

[0353] 

The VirtualAddressSpace class defines the follow- 
ing native methods: 

getAddressSize 

[0354] 

private native int getAddressSize(); 

[0355] Returns the number of bits of virtual addresses 
for this virtual address space (the one in which the call- 
ing thread is running). 

allocjd 

[0356] 

private native int alloc_id(); 

[0357] Each virtual machine runs in a separate virtual 
address space (only one virtual address space on a 
machine with just one virtual machine). This method 
allows the microkernel to specify an ID (only the micro- 
kernel will interpret this ID) which can be used subse- 
quently to identify the particular virtual address space 
for a mapping in native methods of the VirtualMemory 
class. The particular virtual address space is to be the 
one which the head calling this native method is set up 
to use. 

VirtualMemory 

[0358] The VirtualMemory class defines the following 
native methods., which control virtual memory. If a plat- 
form does not really have virtual memory, then virtual 
memory is defined to be mapped (automatically) one- 
to-one to physical memory in such a way that the virtual 
address corresponding to a physical address is the 



same as that physical address. 
[0359] The first three native methods map and unmap 
virtual memory The first native method, physmap(), 
sets up virtual memory mapped to an array of physical 
5 memory ranges, while the second native method, 
map(), simply maps a specified amount of virtual mem- 
ory, without specifying the physical memory to which it 
. maps. The third native method, unmap(), undoes the 
mappings that the other two methods create. 

70 

physmap 
[0360] 

private native int physmap(longfl ret, int vasid. 
75 longQ paddrs, longQ sizes, long minaddr, long max- 
addr, int align, int cacheMode, boolean locked, 
boolean waitformem); 

[0361] The particular virtual address space m which 
20 this mapping is to be done is specified by vasid, which 
the caller is to have obtained via a call to the 
alloc_vasid() native method of the VirtualAddressSpace 
class. 

[0362] The physical memory to be mapped is speci- 
25 fied via the arrays paddrs and sizes in such a way that 
the nth element of paddrs and the nth element of sizes 
specify the base physical address and length for a 
range of physical memory, respectively. These ranges 
of physical memory are to be mapped to increasingly 
30 higher virtual addresses in such a way" that physical 
memory range n (as specified by nth elements of pad- 
drs and sizes) is to be mapped to virtual addresses 
which are lower than the virtual addresses which map to 
physical memory range n+l. Furthermore, the virtual 
35 address ranges are to be contiguous, so that they form 
one virtual address range. 

[0363] For this mapping, any range of virtual 
addresses can be used, except that all virtual 
addresses in the range must be greater than or equal to 
to minaddr, and all virtual addresses in the range must be 
less than or equal to maxaddr. Also, the base virtual 
address is to be aligned as specified by align, which 
could have one of the following values: 

.45 • MemoryConstraints.ALIGN_BYTE (0) - no align- 
ment restriction. 

• MemoryConstraints.ALIGN_SHORT (1) - align to 
short. 

MemoryConstraints.ALIGNJNT (2) - align to int. 
so • MemoryConstraints.ALIGN_LONG (3) - align to 
long. 

• MemoryConstraints.ALIGN_CACHE (4) - align to 
cache line size. 

MemoryConstraints.ALIGN_PAGE (5) - align to 
55 page size. 

[0364] The virtual memory is to be cached as though 
cacheMode were specified for mode in a call to the 
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native method, setcachemode(). 
[0365] If locked is true, the virtual memory mappings 
to the particular physical pages are to be locked as 
though the dolockQ native method had been called. 
[0366] If waitformem is true and it is currently not pos- 5 
sible to complete the mapping request, due to a 
resource running out temporarily, then wait indefinitely 
to complete the request. Otherwise, do not wait. 
[0367] If not all these constraints can be met, but they 
could be met for a smaller sub-range, which must start to 
with the first range of physical memory, then do the 
mapping for that smaller sub-range. For example, if this 
platform does not really have virtual memory, and if the 
physical memory ranges are discontiguous, then obvi- 
ously only the first range of physical memory can be 75 
mapped. 

[0368] The base virtual address of the range is to be 
returned in ret[0] and the length of virtual memory 
mapped is to be returned in ret[1]. 

[0369] The possible return values are: 20 

SUCCESS - The mapping was successful. Either 
the entire amount of physical memory was mapped, 
or at least a sub-range was mapped. 

• ADDRESS_FAILURE - There was some failure 25 
related to the physical addresses specified. For 
whatever reason those addresses are undefined 
physical memory or physical memory for which 
mappings can not be setup. 

• ALLOC_FAILURE - There was some other fatal fail- 30 
ure in the attempt to create the mappings. 

map 

[0370] 35 

private native int map(longQ ret, int vasid, long size, 
long minaddrjong maxaddr, int align, int cacheM- 
ode, boolean locked, boolean waitformem); 

40 

[0371] The particular virtual address space in which 
this mapping is to be done is specified by vasid, which 
the caller is to have obtained via a call to the 
alloc_vasid() native method of the Virtual AddressSpace 
class. 45 
[0372] The amount of virtual memory to allocate is 
specified by size in bytes. For this mapping, any range 
of virtual addresses can be used, except that all virtual 
addresses in the range must be greater than or equal to 
minaddr, and all virtual addresses in the range must be so 
less than or equal to maxaddr. Also, the base virtual 
address is to be aligned as specified by align, which 
could have one of the following values: 

• MemoryConstraints.ALIGN_BYTE (0) - no align- 55 
ment restriction. 

• MemoryConstraints.ALIGN_SHORT (1) - align to 
short. 



• MemoryConstraints.ALIGNJNT (2) - align to int. 

• MemoryConstraints.ALIGN_LONG (3) • align to 
long. 

• MemoryConstraints.ALIGN_CACHE (4) - align to 
cache line size. 

• MemoryConstraints.ALIGN_PAGE (5) • align to 
page size. 

[0373] The virtual memory is to be cached as though 
cacheMode were specified for mode in a call to the 
native method, setcachemodeO- 
[0374] If locked is true, the virtual memory mappings 
to the particular physical pages are to be locked as 
though the do!ock() native method had been called. 
[0375] If waitformem is true and it is currently not pos- 
sible to complete the mapping request, due to a 
resource running out temporarily, then wait indefinitely 
to complete the request. Otherwise, do not wait. 
[0376] If not all these constraints can be met, but they 
could be met for a smaller sub-range, which must start 
with the first range of physical memory,- then do the 
mapping for that smaller sub-range. 
[0377] The base virtual address of the range is to be 
returned in ret[0] and the length of virtual memory 
mapped is to be returned in ret[1]. 
[0378] The possible return values are: 

SUCCESS - The mapping was successful. Either 
the entire amount of physical memory was mapped, 
or at least a sub-range was mapped. 

• ADDRESS_FAILURE - There was some failure 
related to the physical addresses specified. For 
whatever reason those addresses are undefined 
physical memory or physical memory for which 
mappings can not be set up. 

• ALLOC_FAILURE - There was some other fatal fail- 
ure in the attempt to create the mappings. 

unmap 

[0379] 

private native int unmap(int vasid, long base, long 
len.int howcreated); 

[0380] The particular virtual address space in which 
this unmapping is to be done is specified by vasid, 
which the caller is to have obtained via a call to the 
alloc_vasid() native method of the VirtuaLAd- 
dressSpace class. 

[0381] The virtual memory to be unmapped is that 
starting at base and having a length of len in bytes. 
[0382] The howcreated parameter specifies how the 
virtual memory was mapped in the first place: 

• CREATED_MAP - Created via physmapf). 

• CREATED_MALLOC - Created via mapQ. 
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[0383] The possible return values are: 

SUCCESS - The unmapping was a success. The 
entire range specified was unmapped. 

• ALLOC_FAILURE • There was some other fatal fail- s 
ure in the attempt to do the unmapping. 

[0384] The next three native methods lock and unlock 
virtual memory mappings. The native method, dolock(), 
locks virtual memory to particular physical memory 10 
without regard to the underlying physical memory being 
contiguous, while the native method, dolockcontig(), 
does the locking to contiguous physical memory. The 
native method, unlock(), unlocks the mappings that the 
other two methods lock. is 

dolock 

[0385] 

20 

private native int dolock(longQ ret, int vasid, long 
base, long len); 

[0386] The particular virtual address space in which 
this locking is to be done is specified by vasid, which the 
caller is to have obtained via a call to the alloc_vasid() 
native method of the VirtualAddressSpace class. 
[0387] The virtual memory to be locked is that starting 
at base and having a length of len in bytes. 
[0388] When a range of virtual memory is locked, it 
means that the microkernel cannot change the identity 
of the underlying physical memory. Thus, while locked, 
a particular range of virtual memory always maps to the 
same range of physical memory. It should be noted that 
the microkernel needs to maintain a lock count, such 
that each call to lock a particular range must be undone 
by as many calls to the dounlock() native method. 
[0389] If the locking is not successful, this native 
method will not cause any locking of a partial range to 
be done. If the locking was successful, ret[0] will be the 
total number of bytes of the range that are locked (the 
entire length of the range). If the locking was not suc- 
cessful, but if it would have been possible to lock a sub- 
range starting at the beginning of the range, then ret[0] 
is the length of that sub-range. 
[0390] The possible return values are: 

SUCCESS-The locking was a success. The entire 
range specified was locked. 

• NOT_ALL_LOCKED - it would not be possible to 
lock the entire specified range, but it would be pos- 
sible to lock a smaller sub-range starting at the 
beginning, whose length is ret[0]. 

• ALLOC.FAILURE - There was some other fatal fail- 
ure in the attempt to do the unmapping. 



dolockcontig 
[0391] 

private native int dolockcontig(longQ ret, int vasid, 
long base, long len); 

[0392] The particular virtual address space in which 
this locking is to be done is specified by vasid, which the 
caller is to have obtained via a call to the alloc_vasid() 
native method of the VirtualAddressSpace class. 
[0393] The virtual memory to be locked is that starting 
at base and having a length of len in bytes. 
[0394] When a range of virtual memory is locked, it 
means that the microkernel cannot change the identity 
of the underlying physical memory. Thus, while locked, 
a particular range of virtual memory always maps to the 
same range of physical memory. It should be noted that 
the microkernel needs to maintain a lock count, such 
that each call to lock a particular range must be undone 
by as many calls to the dounlock() native method. 
[0395] As opposed to the dolock() native method, this 
particular native method is to do the locking so that the 
entire range of virtual addresses map to contiguous 
physical memory. In order to do this, the microkernel 
may need to remap portions of this virtual range. Note, 
though, that if this remapping violates any locking 
already done via dolock() or dolockcontigO, then this 
dolockcontig() call is to be failed (with 
NOT_ALL_LOCKED). 

[0396] If the locking is not successful, this native 
method will not cause any locking of a partial range to 
be done. If the locking was successful, ret[0] will be the 
total number of bytes of the range that are locked (the 
entire length of the range). If the locking was not suc- 
cessful, but if it would have been possible to lock a sub- 
range starting at the beginning of the range, then ret[0] 
is the length of that sub-range. 
[0397] The possible return values are: 

SUCCESS - The locking was a success. The entire 
range specified was locked contiguously. 
• NOT_ALL_LOCKED - it would not be possible to 
lock the entire specified range, but it would be pos- 
sible to lock contiguously a smaller sub-range start- 
ing at the beginning, whose length is ret[0]. 
ALLOC_FAILURE - There was some other fatal fail- 
ure in the attempt to do the unmapping. 

dounlock 

[0398] 

private native int dounlock(int vasid, long base, long 
len); 



30 
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[0399] The particular virtual address space in which 
this unlocking is to be done is specified by vasid, which 
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the caller is to have obtained -via a call to the 
alloc_vasid() native method of the VirtualAddressSpace 
class. 

[0400] The virtual memory to be unlocked is that start- 
ing at base and having a length of len in bytes. This call 5 
decrements the lock count for the range which had been 
incremented by either the dolockO or the dolockcontig() 
native methods. 

[0401] The possible return values are: 



SUCCESS - The unmapping was a success. The 
entire range specified was unlocked. 
ALLOC_FAILURE - There was some other fatal fail- 
ure in the attempt to do the unlocking. 



getphys 



[0402] 



private native int getphys(intfl ret, int vasid, longQ 
pBase, longQ pLen, long base, long ien); 



10 



75 



20 



[0403] Provided the virtual memory is first locked, it is 
guaranteed that the identity of the underlying physical 
memory will remain the same. A call to the getphysO 25 
native method is used to obtain the underlying physical 
memory. 

[0404] The particular virtual address space in which 
this operation is to be done is specified by vasid, which 
the caller is to have obtained via a call to the so 
alloc_vasidO native method of the VirtualAddressSpace 
class. 

[0405] The base of the range of virtual memory is 
specified by base, and the length of the range by len in 
bytes. 35 
[0406] If the virtual memory is not locked, this call 
does nothing and simply returns FAILURE. 
[0407] The physical memory is to be specified in the 
supplied arrays pBase and pLen, such that the p6ase[0] 
and pLen[0] are the base and length of the physical 40 
memory that starts mapping the beginning of the virtual 
memory, and such that (pBase[n+1], pLen[n+1]) speci- 
fies physical memory to which a higher range of virtual 
addresses is mapped than the range of virtual 
addresses that map the physical memory range speci- 45 
fied by (pBase[n], pLen(n]). 

[0408] It is not possible for the caller to know how 
many discontiguous ranges of physical memory map 
this virtual memory range, so it is possible that the sup- 
plied arrays for pBase and pLen may be too small. If this so 
is the case, the microkernel is to return 
ARRAY_TOO_SMALL and specify the number of ele- 
ments needed in the array in ret[0]. 
[0409] If this call is successful, the number of bits of 
the physical memory on this platform is specified in 55 
ret[1]. 

[041 0] The next native methods control caching of 
data associated with virtual addresses on the particular 



platform. 

setcathemode 

[0411] 

private native void setcachemode(int vasid, long 
base, long len, int mode); 

[0412] The particular virtual address space in which 
this operation is to be done is specified by vasid, which 
the caller is to have obtained via a call to the 
alloc_vasid() native method of the VirtualAddressSpace 
class. 

[041 3] This native method sets the caching for virtual 
memory, starting at the virtual address, base, and con- 
tinuing for a length in bytes of len. The caching is set 
based upon the following possible values of mode (for 
any other values of mode, do nothing): 

• C AC H E_MOD E_D E FAU LT - Cache this range of 
virtual memory according to what the default is for 
this type of virtual memory on this platform. Note 
that, »/en on platforms that have virtual address 
caches, depending upon the underlying -physical 
memory mapped, the virtual memory mapping 
some physical memory (e.g. l/O-registers) may 
need to be uncached, and it is expected that the 
microkernel will make these virtual memory map- 
pings uncached if they need to be uncached to be 
used correctly. Also, note that if the range specified 
encompasses virtual memory mapped to different 
tppes of physical memory that need to be treated 
differently, the microkernel is expected to cache dif- 
ferent sub-ranges differently, if necessary, so that 
the entire range is cached correctly. Other than 
these restrictions, the microkernel should try to set 
up caching to effect the greatest efficiency that is 
correct. In other words, if caches can be used, while 
still maintaining data integrity, they should. 

• CACHE_MODE_INHI3ITED - If it is possible to 
cache this virtual memory, and if it is possible to dis- 
able its caching, then disable its caching. Other- 
wise, do nothing. If this in not possible over the 
entire range, but is possible over one or more sub- 
ranges, do it at least over any such sub-ranges. 

• CACHE_MODE_WRITE_TH ROUGH - if it is possi- 
ble to cache this virtual memory, and if it is possible 
to set the cache to write-through mode, then set it 
as such. Otherwise, do nothing. If this in not possi- 
ble over the entire range, but is possible over one or 
more sub-ranges, do it at least over any such sub- 
ranges. 

• CACHE_MODE_COPY_BACK - If it is possible to 
cache this virtual memory, and if it is possible to set 
the caching to copy-back mode, then set it as such. 
Otherwise, do nothing. If this in not possible over 
the entire range, but is possible over one or more 
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sub-ranges, do it at least over those sub-ranges. address space, the microkernel simply returns 0, 



getcachemode 
[0414] 

private native int getcachemode(int vasid, long 
base, long len); 

[041 5] This native method gets the caching for virtual 
memory, starting at the virtual address, base, and con- 
tinuing for a length in bytes of len. One of the following 
values is to be returned: 

• CACHEJvlODE_AMBIGUOUS - If the entire range 
is not cached the same way, or if none of the follow- 
ing return values apply. 

• CACHEJWODEJNIHIBITED - If there is no cache, 
or if there is a cache, but this virtual memory range 
is now uncached. 

• CACHE_MODE_WRlTE_THROUGH - If this range 
of virtual memory is now cached in writ-through 
mode. 

• CACHE_MODE_COPY_BACK - If this range of vir- 
tual memory is now cached in copy-back mode. 

flushcache 

[0416] 

private native void flushcache(int vasid, long base, 
long len); 

[041 7] If any sub-range of this range of virtual memory 
is cached in CACHE_MODE_COPY_BACK mode, flush 
any such caches if possible. If it is not possible to flush 
them, convert them to CACHE_MODE_INHlBITED. 

DMAAddressSpace 

[0418] The DMAAddressSpace class defines the fol- 
lowing native methods: 

getAddressSize 

[0419] 

private native int getAddressSize(); 

Returns the number of bits of DMA addresses 
alloc_id 
[0420] 

private native int alloc Jd(); 



DMAMemory 

5 [0422] The DMAMemory class defines the following 
native methods. Each of these native methods is imple- 
mented by functionality in the microkernel. 



private native boolean supported(); 

[0424] Returns true if DMA is supported on this plat- 
75 form; otherwise returns false. 

physmap 



private native int physmap(long[] ret, longQ paddrs, 
long[) sizes.long minaddr, long maxaddr, int align, 
boolean waitformem) ; 

25 [0426] The physical memory to be mapped is speci- 
fied via the arrays paddrs and sees in such a way that 
the nth element of paddrs and the nth element of sizes 
specify the base physical address and length for a 
range of physical memory, respectively. These ranges 

30 of physical memory are to be mapped to increasingly 
higher DMA addresses in such a way that physical 
memory range n (as specified by nth elements of pad- 
drs and sizes) is to be mapped to DMA addresses which 
are lower than the DMA addresses which map to physi- 

35 cal memory range n+1. Furthermore, the DMA address 
ranges are to be contiguous, so that they form one DMA 
address range. 

[0427] For this mapping, any range of DMA addresses 
can be used, except that all DMA addresses in the 
40 range must be greater than or equal to minaddr, and all 
DMA addresses in the range must be less than or equal 
to maxaddr. Also, the base DMA address is to be 
aligned as specified by align, which could have one of 
the following values: 

45 

MemoryConstraints.ALIGN_BYTE (0) - no align- 
ment restriction. 

• MemoryConstraints.ALIGN_SHORT (1) - align to 
short. 

so • MemoryConstraints.ALIGNJNT (2) - align to int. 

• MemoryConstraints.ALlGN_LONG (3) - align to 
long. 

• MemoryConstraintsALIGN_CACHE (4) - align to 
cache line size. 

55 • MemoryConstraints.ALIGN_PAGE (5) - align to 
page size. 



supported 
10 [0423] 



[0425] 

20 



[0421] Since it is assumed that there is only one DMA 



[0428] If waitformem is true and it is currently not pos- 
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sible to complete the mapping request, due to a 
resource running out temporarily, then wait indefinitely 
to complete the request. Otherwise, do not wait. 
[0429] If not all these constraints can be met, but they 
could be met for a smaller sub-range, which must start 
with the first range of physical memory, then do the 
mapping for that smaller sub-range. For example, if this 
platform does not really have DVMA (Direct Virtual 
Memory Addressing), and if the physical memory 
ranges are discontigous, then obviously only the first 
range of physical memory can be mapped. 
[0430] The base DMA address of the range is to be 
returned in ret[0] and the length of DMA memory 
mapped is to be returned in ret[1]. 
[0431] The possible return values are: 

SUCCESS - The mapping was successful. Either 
the entire amount of physical memory was mapped, 
or at least a sub-range was mapped. 

• ADDRESS_FAILURE - There was some failure 
related to the physical addresses specified. For 
whatever reason those addresses are undefined 
physical memory or physical memory for which 
mappings can not be set up. 

• ALLOC_FAILURE - There was some other fatal fail- 
ure in the attempt to create the mappings. 

map 

[0432] 

private native int map(longQ ret, long size, long 
minaddrjong maxaddr, int align, boolean wait- 
for mem); 

[0433] The amount of DMA memory to allocate is 
specified by size in bytes. For this mapping, any range 
of DMA addresses can be used, except that all DMA 
addresses in the range must be greater than or equal to 
minaddr, and all DMA addresses in the range must be 
less than or equal to maxaddr. Also, the base DMA 
address is to be aligned as specified by align, which 
could have one of the following values: 



resource running out temporarily, then wait indefinitely 
to complete the request. Otherwise, do not wait. 
[0435] If not all these constraints can be met, but they 
could be met for a smaller sub-range, which must start 

5 with the first range of physical memory, then do the 
mapping for that smaller sub-range. 
[0436] The base DMA address of the range is to be 
returned in ret[0] and the length of DMA memory 
mapped is to be returned in ret[1]. The possible return 

10 values are: 

SUCCESS - The mapping was successful. Either 
the entire amount of physical memory was mapped, 
or at least a sub-range was mapped. 

75 • ADDRESS_FAILURE - There was some failure 
related to the physical addresses specified. For 
whatever reason those addresses are undefined 
physical memory or physical memory for which 
mappings can not be set up. 

20 • . ALLOC_FAILURE - There was some other fatal fail- 
ure in the attempt to create the mappings. 

unmap 

25 [0437] 

private native int unmap(long base, long len); 

[0433] The DMA memory to be unmapped is that 
30 starting at base and having a length of len in bytes. 
[0439] The possible return values are: 

SUCCESS - The unmapping was a success. The 
entire range specified was unmapped. 
35 • ALLOC_FAILURE - There was some other fatal fail- 
ure in the attempt to do the unmapping. 

getphys 

40 [0440] 

private native int getphys(intQ ret, longQ pBase, 
longQ pLen, long base, long len); 



MemoryConstraints.ALIGN_BYTE (0) - no align- 45 
ment restriction. 

• MemoryConstraints.ALIGN_SHORT (1) - align to 
short. 

MemoryConstraints. ALIGNJNT (2) - align to int. 

• MemoryConstraints.ALIGNJ_ONG (3) - align to so 
long. 

• MemoryConstraints.ALIGN_CACHE (4) - align to 
cache line size. 

• MemoryConstraints.ALIGN_PAGE (5) - align to 
page size. ss 

[0434] If waitformem is true and rt is currently not pos- 
sible to complete the mapping request, due to a 



[0441 ] The base of the range of DMA memory is spec- 
ified by base, and the length of the range by len in bytes. 
[0442] The physical memory is to be seed in the sup- 
plied arrays pBase and pLen, such that the pBase[0] 
and pLen[0] are the base and length of the physical 
memory that starts mapping the beginning of the DMA 
memory, and such that (pBase[n+1], pLen[n+1]) speci- 
fies physical memory to which a higher range of DMA 
addresses is mapped than the range of DMA addresses 
that map the physical memory range specified by 
(pBase[n], pLen[n]). 

[0443] It is not possible for the caller to know how 
many discontignous ranges of physical memory map 
this DMA memory range, so it is possible that the sup- 
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plied arrays for pBase and pLen may be too small. If this 
is the case, the microkernel is to return 
ARRAY_TOO_SMALL and specify the number of ele- 
ments needed in the array in ret[0]. 
[0444] If this call is successful, the number of bits of 
the physical memory on this platform is specified in 
ret[1]. 

AccessibleMemory Sub-Classes 

[0445] The various non-abstract sub-classes of 
AccessibleMemory define as native methods the meth- 
ods abstracted in AccessibleMemory. These sub- 
classes consist of Swapped Virtual lOMemory, 
UnSwappedVirtuallOMemory, SwappedVirtualRegu- 
larMemory, UnSwappedVirtualRegularMemory, 
SwappedPortlOMemory, and UnSwappedPortlOMem- 
ory. For each of these sub-classes there are separate 
versions of these native methods. 
[0446] These separate versions of native methods are 
mostly similar to one another, with their differences 
specH ied by the following flavors: 

Swapped/Un Swapped - Versions of the native 
methods for swapped classes (SwappedVirtuall- 
OMemory Swapped Virtual RegularMemory and 
SwappedPortlOMemory) must byte-swap (reverse 
the endianness) any data they get from the native 
methods before operating upon it, and must byte- 
swap back any data they supply to the classes. The 
other classes (UnSwappedVirtuallOMemory, 
UnSwapped Virtual RegularMemory, and 
UnSwappedPortlOMemory) are not to have any 
such byte-swapping done. 
IO/Regular • Classes supporting IO memory 
(SwappedVirtual lOMemory and UnSwappedVirtu- 
allOMemory) may require special platform-specific 
(implementation dependent) operations to be done 
whenever accesses are done to that memory. 
Classes supporting regular RAM memory 
(SwappedVirtualRegularMemory and UnSwapped- 
VirtualRegularMemory) do not require any such 
special platform-specific operations. Note that on 
some platforms, there is no difference. 
VirtualPort - Classes for virtual memory (Swapped- 
VirtuallOMemory, UnSwappedVirtuallOMemory, 
SwappedVirtualRegularMemory and UnSwapped- 
VirtualRegularMemory) can assume that memory 
is accessed via normal load and store instructions, 
and that the addresses specified in the native meth- 
ods refer to virtual memory addresses. Classes for 
port memory (SwappedPortlOMemory and 
UnSwappedPortlOMemory) must do special I/O 
instructions to access memory. 

[0447] Modulo the above specification of flavors, the 
following is specified for each of these six sets of native 
methods: 



supported 
[0448] 

5 protected native boolean supported(); 

[0449] Returns true if this particular sub-ctass of 
AccessibleMemory is supported on this platform; other- 
wise returns false. 

w 

ncksum 
[0450] 

is protected native int ncksum(long adr, long len); 

[0451] Computes a sum of the bytes of the memory 
(modulo Ox 10000) starting at the address adr for the 
length len in bytes. 

20 

nSetByte 
[0452] 

25 protected native void nsetByte(long adr, byte x); 

[0453] This operation must be done with respect to the 
following particular flavors (see above) of the specific 
subclass of AccessibleMemory which this native 
30 method supports: IO/Regular, Virtual/Port. 

[0454] The byte value, x, is to be written at the 
address, adr. 

nSetShort 

35 

[0455] 

protected native void nsetshort(long adr, short x); 

40 [0456] This operation must be done with respect to the 
following particular flavors, (see above) of the specific 
sub-class of AccessibleMemory which this native 
method supports: Swapped;UnSwapped, IO/Regular, 
Virtual/Port. 

45 [0457] The short value, x, is to be written at the 
address, adr. 

nSetlnt 

so [0458] 

protected native void nSetlnt(long adr, int x); 

[0459] This operation must be done with respect to the 
55 following particular flavors (see above) of the specific 
sub-class of AccessibleMemory which this native 
method supports: Swapped/UnSwapped, IO/Regular, 
Virtual/Port 
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[0460] The int value, x, is to be written at the address, 
adr. 

nSetLong 
[0461] 

protected native void nsetlong(long adr, long x); 

[0462] This operation must be done with respect to the 
following particular flavors (see above) of the specific 
sub-class of AccessibleMemory which this native 
method supports: Swapped/UnSwapped, lO/Regular, 
Virtual/Port. 

[0463] The long value, x, is to be written at the 
address, adr. 

nSetBytes 

[0464] 

protected native void nsetBytes(long adr, byte 
bytesQ, int bytesOffset, int length); 

[0465] This operation must be done with respect to the 
following particular flavors (see above) of the specific 
sub-class of AccessibleMemory which this native 
method supports: Swapped/UnSwapped, IO/Regular. 
Virtual/Port. 

[0466] Starting at the offset, bytesOffset, of the array, 
bytes, the array of bytes is to be written starting at the 
address adr, for a total length in bytes of length. 

nSetlntArmy 

[0467] 

protected native void nSetlntArray(long adr, byte 
bytesQ, int bytesoffset, int length jnt); 

[0468] This operation must be done with respect to the 
following particular flavors (see above) of the specific 
sub-class of AccessibleMemory which this native 
method supports: Swapped/UnSwapped, IO/Regular, 
Virtual/Port. 

[0469] Starting at the offset, bytesOffset, of the anray, 
bytes, the array of bytes is to be written, treating it as an 
array of integers, starting at the address adr, for a total 
length in integers of lengthjnt. 

nGetByte 

[0470] 

protected native byte nGetByte(long adr); 

[0471 ] This operation must be done with respect to the 
following particular flavors (see above) of the specific 
sub-class of AccessibleMemory which this native 



method supports: IO/Regular, Virtual/Port. 

[0472] Read and return a byte from the address, adr. 

nGetShort 

5 

[0473] 

protected native short nGetshort(long adr); 

io [0474] This operation must be done with respect to the 
following particular flavors (see above) of the specific 
sub-class of AccessibleMemory which this native 
method supports: Swapped/UnSwapped, IO/Regular, 
Virtual/Port. 

75 [0475] Read and return a short from the address, adr. 
nGetlrrt 
[0476] 

20 

protected native int nGetlnt(long adr); 

[0477] This operation must be done with respect to the 
following particular flavors (see above) of the specific 
25 sub-class, of AccessibleMemory which this native 
method supports: Swapped/UnSwapped, IO/Regular, 
Virtual/Port. 

[0478] Read and return an int from the address, adr. 
30 nGetLong 
[0479] 

protected native long nGeti_ong(long adr); 

35 

[0480] This operation must be done with respect to the 
following particular flavors (see above) of the specific 
sub-class of AccessibleMemory which this native 
method supports: Swapped/UnSwapped, IO/Regular, 
40 Virtual/Port. 

[0481 ] Read and return a long from the address, adr. 

nGetBytes 

45 [0482] 

protected native void nGetBytes(long adr, byte 
bytesQ, int bytesOffset, int length); 

so [0483] This operation must be done with respect to the 
following particular flavors (see above) of the specific 
sub-class of AccessibleMemory which this native 
method supports: Swapped/UnSwapped, IO/Regular, 
Virtual/Port. 

55 [0484] Start reading bytes from adr for a total of length 
bytes, and read them into the array bytes, starting at the 
offset of bytesOffset of that array. 
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nGetlntArray 
[0485] 

protected native void nGetlntArray(long adr, byte 5 
bytesQ. int bytesOffset, int length jnt); 

[0486] This operation must be done with respect to the 
following particular flavors (see above) of the specific 
sub-class of AccessibleMemory which this native 10 
method supports: Swapped/UnSwapped, IO/Regular, 
Virtual/Port. 

[0487] Start reading ints from adr for a total of length- 
jnt ints, and read them into the array bytes, starting at 
the offset of bytesOffset of that array. is 



nRegisterSource 



[0488] 



protected native Void nRegisterSource(long adrl, 
longlen); 



[0496] It wilt be apparent to those skilled in the art that 
various modifications and variations can be made in the 
disclosed process and product without departing from 
the scope or spirit of the invention. Other embodiments 
of the invention will be apparent to those skilled in the 
art from consideration of the specification and practice 
of the invention disclosed herein. It is intended that the 
specification and examples be considered as exemplary 
only, with a true scope and spirit of the invention being 
indicated by the following claims. 
[0497] The features disclosed in the foregoing 
description, in the claims and/or in the accompanying 
drawings may, both separately and in any combination 
thereof, be material for realising the invention in diverse 
forms thereof. 

Claims 



1. A method for providing memory functionality to 
20 object-oriented client software components of a 
computer system having a CPU, comprising the 
steps of: 



[0489] This operation registers the source of a copy 
operation, and returns an ID, which can later be passed 25 
to the nCopy native method. The base address of the 
source, adrl , and the length in bytes to copy, len, are to 
be registered. It is also necessary to take into account 
and register the following flavors depending upon the 
particular nature of the source memory: 30 
Swapped/UnSwapped, IO/Regular, Virtual/Port. 

nCopy 

[0490] 35 



providing a first set of memory classes, each 
class of the first set being platfornvindepend- 

ent: 

providing a second set of memory classes, 
each class of the second set being a subclass 
of a class of the first set and being platform- 
dependent; and 

performing client component memory functions 
by accessing only objects of classes of the first 
set. 



protected native void nCopy(long adr2, long len, int 
copy ID); 

[0491 ] This operation performs a copy from the source 
as specified by copylD, to the destination specified here. 
[0492] If copylD does not correspond to a registered 
source, do nothing. 

[0493] The destination address, adr2, and length in 
bytes, len, are as specified. The source address and 
length may be obtained by what was registered for the 
source, as specified by copylD. If the length of source 
and destination do not agree, use the lesser of the two. 
[0494] In performing this copy, it is necessary to take 
into account the following flavors for both the source and 
destination: Swapped/UnSwapped, IO/Regular, Vir- 
tual/Port. 

[0495] The classes described above are stored on a 
computer readable medium, such as floppy disks, a CD- 
ROM, or optical disk. Alternatively, they are supplied to 
computer system 10 in a read-only memory, or provided 
in the form of a computer data carrier wave over a net- 
work. 



2. A method as recited in claim 1 , wherein the step of 
providing a first set of memory classes includes the 
substep of providing a first abstract memory class 

40 having only the attributes of base address, length, 
and constraints. 

3. A method as recited in claim 2, wherein the step of 
providing a first set of memory classes includes the 

45 substep of providing a first instantiate class of 
memory which extends the first abstract memory 
class and which provides no functionality beyond 
that provided by the first abstract memory class. 

so 4. A method as recited in claim 2, wherein the step of 
providing a first set of memory classes includes the 
substep of providing a second abstract memory 
class which extends the first abstract memory class 
and which specifies only abstract methods for con- 

55 trolling cache memory 

5. A method as recited in claim 4, wherein the step of 
providing a first set of memory classes includes the 
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substep of providing a third abstract memory class 
extending the second abstract memory class and 
representing all memory that can be directly 
accessed by the CPU. 



94 



6. A method as recited in claim 5, wherein the substep 
of providing a third abstract memory class includes 
the substep of providing a third abstract memory 
class which defines platform-independent abstract 
methods for accessing memory. 

7. A method as recited in claim 1 , wherein the step of 
providing a second set of memory classes includes 
the substep of providing a second instantiate 
memory class, extending the second abstract 
memory class, which represents physical memory 

8. A method as recited in claim 7, wherein the substep 
of providing a second instantiate memory class 
comprises the substep of providing a second 
instantiable memory class which provides imple- 
mentations of cache management methods 
abstracted in the second abstract memory class. 

9. A method as recited in claim 8, wherein the step of 
providing a second set of memory classes includes 
the substep of providing a fourth abstract memory 
class, which extends the third abstract memory 
class, and which contains methods for setting up 
mappings to objects of the second instantiable 
memory class and a method for allocating a specific 
amount of virtual memory without specifying a par- 
ticular physical memory. 



10 



14. 



15 



20 



classes includes the substep of providing a 
second abstract memory class which extends 
the first abstract memory class and which 
specifies only abstract methods for caching 
memory; and 

the step of providing a second set of memory 
classes includes the substeps of providing 
native methods in the second group of meth- 
ods corresponding to the abstract cache man- 
agement methods defined in the second 
abstract memory class. 

Apparatus for performing memory functions in an 
object-oriented computer system, comprising: 

a first set of memory classes, each class of the 
first set being platform-independent; 

a second set of memory classes, each class of 
the second set being a subclass of a class of 
the first set and being platform-dependent; 



25 



a device driver accessing 
classes of the first set; and 



only objects of 



a bus manager accessing classes of the sec- 
ond set. 

30 15. A computer-readable medium containing instruc- 
tions for providing memory functionality to object- 
oriented client software components of a computer 
system having a CPU , comprising: 



1 0. A method as recited in claim 1 , wherein the step of 35 
providing a second set of memory classes includes 
the substep of providing a third instantiable memory 
class, which extends the first abstract memory 
ciass, for setting up DMA mapping to physical 
memory and for doing corresponding unmapping. 40 



a first set of memory classes, each class of the 
first set being platform-independent; and 

a second set of memory classes, each class of 
the second set being a subclass of a class of 
the first set and being platform-dependent. 



1 1 . A method as recited in claim 1 , wherein the step of 
providing a second set of memory classes includes 
the substep of providing a second set of memory 
classes in which methods are separated into two 45 
groups, the first group being written in non-native 
language and the second group being written in 
native language. 

12. A method as recited in claim 1 1 , wherein the step of so 
providing a second set of memory classes includes 

the substep of providing the second group of meth- 
ods in a library of functions which access the micro- 
kernel. 

55 

1 3. A method as recited in claim 12, wherein: 

the step of providing a first sekol memory 



16. A computer-readable medium as in 15, wherein the 
second set of classes includes a first subset of 
methods written in a platform-independent lan- 
guage and a second subset of methods written in 
native code. 

17. A computer data signal on a carrier wave contain- 
ing instructions for providing memory functionality 
to object-oriented client software components of a 
computer system having a CPU , comprising: 

a first set of memory classes, each class of the 
first set being platform-independent; and 

a second set of memory classes, each class of 
the second set being a subclass of a class of 
the first set and being platform-dependent. 
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